Thread (133 messages) 133 messages, 11 authors, 2022-12-16

Re: [dpdk-dev] [PATCH v3 6/9] eal: register non-EAL threads as lcores

From: Ananyev, Konstantin <hidden>
Date: 2020-06-24 10:45:43

24/06/2020 11:56, Bruce Richardson:
quoted
On Wed, Jun 24, 2020 at 11:23:55AM +0200, David Marchand wrote:
quoted
On Tue, Jun 23, 2020 at 3:16 PM Ananyev, Konstantin
[off-list ref] wrote:
quoted
quoted
Even before this series, MP has no protection on lcore placing between
primary and secondary processes.
Agree, it is not a new problem, it has been there for a while.
Though making lcore assignment dynamic will make it more noticeable and harder to avoid.
With static only lcore distribution it is much easier to control things.
quoted
Personally, I have no use for DPDK MP and marking MP as not supporting
this new feature is tempting for a first phase.
If this is a strong requirement, I can look at it in a second phase.
What do you think?
In theory it is possible to mark this new API as not supported for MP.
At least for now. Though I think it is sort of temporal solution.
AFAIK, MP is used by customers, so sooner or later someone will hit that problem.
I understand this argument.
But then we don't see those customers giving feedback.

quoted
Let say, we do have pdump app/library in our mainline.
As I can see - it will be affected when users will start using this new dynamic lcore API
inside their apps.
Supporting lcore allocation in MP requires exchanges between
primary/secondary processes like what we have for memory allocations.
It will be quite a beast to get to work fine, while not even knowing
if people actually want to use both.

For v4, I added a check to exclude MP and the new API.
I am still willing to help if people do care about using both features together.
I wonder how much we could simplify DPDK generally if we had to enable a
specific runtime flag to enable multi-process support and it was off by
default. This would break proc_info I think, but maybe we could provide
telemetry callbacks to provide the same data, but beyond that it would just
allow us to know whether a DPDK app is actually using MP, or just running
as a single process.
Same thought here.
I like the idea of a "mode flag" when multi-process is in use.
Should it be an user explicit flag or an automatic one?
It is probably possible, but that would mean will need to start splitting
core parts of DPDK code into two paths: standalone/MP, right?   
Wonder how much effort it would require in terms of code  rework, testing,
maintenance, etc. At first glance seems quite substantial.

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help