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

[Jean Tourrilhes <jt@labs.hpe.com>]

On Tue, Oct 04, 2016 at 02:11:39PM +0100, Sergio Gonzalez Monroy wrote:
> Hi Jean,
> 
> As with your other patch, commit title needs fixing and also missing
> Signed-off-by line.

	I'll do that, no worries...

> I might be missing something here so bear with me.

	Yes, I know I was terse. Sorry.

> 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.

	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 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 guess the assumption here is that all the TAILQ infrastructure works even
> when the tailq list itself is NULL?

	If tailq are not used in the primary, I assume it would work.

> I say assumption because I don't have an easy way to trigger this use case
> with default DPDK sample/test apps.

	I know. I'll see what I can do to release the code.

> What about letting the secondary process create a tailq if it doesn't
> exists?

	Primary owns the shared memory, and I don't see how primary
could handle an unknown tailq. Secondary can't do much without
primary. So, I don't see how adding the missing tailqs helps.

> We would need to lock protect at least the register function to avoid race
> conditions when having multiple secondary processes.
> 
> David, what do you think?
> 
> Sergio

	Regards,

	Jean