From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g2t2352.austin.hpe.com (g2t2352.austin.hpe.com [15.233.44.25]) by dpdk.org (Postfix) with ESMTP id 9A7292BF7 for ; Tue, 4 Oct 2016 18:59:33 +0200 (CEST) Received: from g2t2360.austin.hpecorp.net (g2t2360.austin.hpecorp.net [16.196.225.135]) by g2t2352.austin.hpe.com (Postfix) with ESMTP id D322F3F; Tue, 4 Oct 2016 16:59:32 +0000 (UTC) Received: from postal.labs.hpecorp.net (mailhub-pa.labs.hpe.com [16.111.35.25]) by g2t2360.austin.hpecorp.net (Postfix) with ESMTP id A49304F; Tue, 4 Oct 2016 16:59:32 +0000 (UTC) Received: from bougret.labs.hpecorp.net (bougret.labs.hpecorp.net [16.111.8.16]) by postal.labs.hpecorp.net (8.14.4/8.14.4/HPL-PA Hub) with ESMTP id u94GxUC5031254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 4 Oct 2016 09:59:30 -0700 Received: from jt by bougret.labs.hpecorp.net with local (Exim 4.84_2) (envelope-from ) id 1brT3y-0000ib-64; Tue, 04 Oct 2016 09:59:30 -0700 Date: Tue, 4 Oct 2016 09:59:30 -0700 From: Jean Tourrilhes To: Sergio Gonzalez Monroy Cc: dev@dpdk.org, David Marchand Message-ID: <20161004165930.GA2012@labs.hpe.com> References: <20160922204637.GA3166@labs.hpe.com> <20160922211728.GA3124@labs.hpe.com> <20493efb-6822-0847-3685-819c769e5ad2@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20493efb-6822-0847-3685-819c769e5ad2@intel.com> Organisation: HP Labs Palo Alto Address: HP Labs, MS1184, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jean.tourrilhes@hpe.com User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: jean.tourrilhes@hpe.com List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 16:59:33 -0000 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