From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id 05C14592A for ; Wed, 5 Oct 2016 09:58:22 +0200 (CEST) Received: by mail-wm0-f44.google.com with SMTP id k125so251308714wma.1 for ; Wed, 05 Oct 2016 00:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lyEUrYb81qHCoVYEx6/i4UHCXyiwsZfjGvg5yCB4mv8=; b=BeacdsRQlUyydYehp+Y8Lp499ui3BcrmyZgrFyVs1aDbL5dKTgBwJJ7DspYEk9Vd+x jZT6kDPGerddQCZC1nRjJfr9vOFGIXpqF6U+Q2GnSgl7fOMQGAp03PuRTcza6KFMtIj5 bb9sifgMisibhIAErsXGzzANQcN76NM5/oW0a8/BbG2AOngxcsW8X4OzsxW2jnCo4twp vHcr97OrIpd7GYfFP6didJhqEMY09E4Kn0yJtvXQRPdTbwsOHu5TzmI8dWFtscfhOi5T pTex/ZH0t27zZNVrW8i0DHv9YkWUpqlIYeEW0/+kJTLxIB7B005KeXMRIacpmGf+pK8T CoRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lyEUrYb81qHCoVYEx6/i4UHCXyiwsZfjGvg5yCB4mv8=; b=lCkLcoham7jQgIubGRYjVsmNbW1E2DnHBjaEYG/n3Vp52jx9oLKYiu5WJgRwWCdmk7 gVFGuCGMCT2WZsECCTZ7EPoKfYGL21zM49/RRc+6z/900Yh5yEXsmS33aym41SwNU1fX VeuHBwXCDpEQdTsA27jMy+E2S7hlCwYJX0UhhP8umENaRYUhYIfJRnvoCqGH+1DJz5Rm aepNLQ/9ULsRwPfXGrWSgvBjHT2KVc0UPgyIyhDEQDPg4qyAEj6dt9BT6L0o40Klmi2K 0PQiz4QebRs9qgnsLTBZD91t1CXb6BfRqEMMRrHjcrQo8DN+2BYOKUeHb/eBtRX61gDE iOHA== X-Gm-Message-State: AA6/9RnZ/Xy+j56WhhmTRvCoA54XxFF5PLCw592Q0yYBenrrbGJAaQBCZ8ZSZw8VEjArYgQ7QXBAAGWe2A6nfukP X-Received: by 10.28.10.138 with SMTP id 132mr20214776wmk.1.1475654301754; Wed, 05 Oct 2016 00:58:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.95.130 with HTTP; Wed, 5 Oct 2016 00:58:01 -0700 (PDT) In-Reply-To: <20161004165930.GA2012@labs.hpe.com> References: <20160922204637.GA3166@labs.hpe.com> <20160922211728.GA3124@labs.hpe.com> <20493efb-6822-0847-3685-819c769e5ad2@intel.com> <20161004165930.GA2012@labs.hpe.com> From: David Marchand Date: Wed, 5 Oct 2016 09:58:01 +0200 Message-ID: To: jean.tourrilhes@hpe.com Cc: Sergio Gonzalez Monroy , "dev@dpdk.org" Content-Type: text/plain; charset=UTF-8 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 List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 07:58:22 -0000 Hello, On Tue, Oct 4, 2016 at 6:59 PM, Jean Tourrilhes 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