OpenVisualCloud / OpenVisualCloud/Media-Transport-Library

Documentation for manually managing lcores

Open
#1,179 0 comments 0 reactions 4 assignees View on GitHub

@skolelis is already working on this.

Since Jun 16, 2025.

Dominant language
C
Stars
246
Forks
88
Avg merge
7d 16h
Merged PRs (30d)
22

Description

This is a request for information (and perhaps updating the official docs).

We are building a system with multiple independent processes, each using MTL for Rx,Tx,or both.
We prefer not to use the MTL manager as it's a single point of failure and not deterministic.
Our current approach is to manage the MTL processes (lcores / affinity) ourselves.

Questions we have:

  1. In the MTL init, how many lcores should we provide to a given process? (is it related to the # of streams?)

  2. What tasks/threads run on these lcores? We see the first core in the list spinning at 100% as expected, what about the others?

  3. We see a second init parameter called 'main_lcore'. What is the purpose of this versus the lcores parameter? The docs recommend leaving it at zero, but should we be setting this too for our use-case? If so, should it be a value that is listed in the lcores, or distinct from that set?

  4. As mentioned in issue 1176 - is there a shared memory data structure that the MTL processes are using for lcore coordination? If so, is there a way to turn that off since we are allocating a unique set of lcores to each process already?

These are the main questions we have at this time. Any other supporting information is also welcome!
Thanks

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.