From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ferruh Yigit Subject: Re: [PATCH v2] eal: don't fail secondary if primary is missing tailqs Date: Fri, 21 Dec 2018 15:50:34 +0000 Message-ID: References: <20160922204637.GA3166@labs.hpe.com> <20161005164906.GB11912@labs.hpe.com> <7491622.GqnA43pcBO@xps13> <20161005174734.GC12182@labs.hpe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: dpdk-dev , olivier.matz@6wind.com, David Hunt , David Marchand To: Jean Tourrilhes Return-path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 258711BE39 for ; Fri, 21 Dec 2018 16:50:37 +0100 (CET) In-Reply-To: <20161005174734.GC12182@labs.hpe.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/5/2016 6:47 PM, jt at labs.hpe.com (Jean Tourrilhes) wrote: > If the primary and secondary process were build using different build > systems, the list of constructors included by the linker in each > binary might be different. Tailqs are registered via constructors, so > the linker magic will directly impact which tailqs are registered with > the primary and the secondary. > > DPDK currently assumes that the secondary has a subset of the tailqs > registered at the primary. In some build scenario, the secondary might > register a tailq that the primary did not register. In this case, > instead of exiting with a panic, just unregister the offending tailq > and allow the secondary to run. > > Signed-off-by: Jean Tourrilhes A lot changed in multiprocess support in last two years, updating status of this patch as 'Rejected', if the issue is still valid can you please either send a new version or report the issue in bugzilla? Thanks, ferruh