Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[David Marchand <david.marchand@6wind.com>]

Hello,

On Tue, Oct 4, 2016 at 6:59 PM, Jean Tourrilhes <jt@labs.hpe.com> wrote:
> On Tue, Oct 04, 2016 at 02:11:39PM +0100, Sergio Gonzalez Monroy wrote:
>> The case you are trying to fix is, as an example, when your secondary app is
>> using LPM but your primary is not.
>> So basically with this patch, you are removing the tailq for LPM on
>> secondary and continuing as normal, is that the case?
>
>         The secondary can't use tailq types that the primary does not
> have, because they are shared across the shared memory.

I am not a "multi process" user but afaik the primary process is
responsible for filling the shared memory.
The secondary processes look at it.
So having unaligned processes can't work.


>         What happens is that the primary and secondary did not compile
> in the same list of tailq. See previous e-mail :
>                 http://dpdk.org/ml/archives/dev/2016-September/047329.html
>         The reason it's happening is that the secondary was not
> compiled with the DPDK build system, but with the build system of the
> application (in this case, Snort). Oubviously, porting the application
> to the DPDK build system is not practical, so we need to live with
> this case.
>         The build system of the application does not have all the
> subtelties of the DPDK build system, and ends up including *all* the
> constructors, wether they are used or not in the code. Moreover, they
> are included in a different order. Actually, by default the builds
> include no constructors at all (which is a big fail), so the library
> needs to be included with --whole-archive (see Snort DPDK
> instructions).

I thought you had unaligned binaries.
You are compiling only one binary ?


>> I am not convinced about this approach.
>
>         I agree that the whole constructor approach is flaky and my
> patch is only a band aid. Constructors should be entirely removed
> IMHO, and a more deterministic init method should be used instead of
> depending on linker magic.
>         Note that the other constructors happen to work right in my
> case, but that's probably pure luck. The list of mempool constructors
> happen to be the same and in the same order (order matters for mempool
> constructors). The app is not using spinlock, hash, crc and acl, so
> I did not look if the lists did match.


I am not sure Sergio is talking about the constructor approach.

Anyway, the constructors invocation order should not matter.
Primary and secondary processes build their local tailq entries list
in constructors (so far, I can't see how this is wrong).
"Later", each process updates this list with the actual pointer to the
lists by looking at the shared memory in rte_eal_init (calling
rte_eal_tailqs_init).

What matters is that secondary tailqs are a subset of the primary tailqs.


I still have some trouble understanding what you are trying to do.
As Sergio asked, can you come up with a simplified example/use case ?

Thanks.


-- 
David Marchand