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

On Wed, Jun 24, 2020 at 11:23:55AM +0200, David Marchand wrote:

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.

/Bruce