From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 7B3124F90 for ; Tue, 13 Nov 2018 17:06:46 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0F82222A0F; Tue, 13 Nov 2018 11:06:46 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 13 Nov 2018 11:06:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=VJNBdJYDCDr2KlS8QcTcbT4zkSSDSgI+Kzc3JImPCe0=; b=pBMP8XAG0YQN Am2QH396/Py3bXCmDXp9UtLwjGJyF15TNHZMsRGQZuWQL2gbC1rkdvLRNQtZyAxK LQb/cL73vzzYuX2svVoyLsGrAJuh2UYWvRWPnx6MxHoidXhdiBtUPeX3fMiLU/8Q FoNQMqSHVwp5S29l2PgAkhFlrV7gCm4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=VJNBdJYDCDr2KlS8QcTcbT4zkSSDSgI+Kzc3JImPC e0=; b=bVLzrdzIgAlAgvlwxCZiLfPfo8RHnUULumn3xwpT8Tp/OskfQ288gyMxU DEfl5gjwd9BWd7MmUQpq3pQI6RmXbKnDJUIGBt/g4dl16TAAMk+TqcL8tvNoBB0I 2AW/eh86q5CMqjTqgomagRtR+5oQc4jczUMYPMX+PxhmWBh7hZ79EYu+X7IYJkTh e7pZISLgX+dv0pwnq52CiccYfJqMaNTSteDHkCTHKLl8WNPvgWSTtGzKKhvoXHc/ FUhEM1A5SrIBLSU8FkutnSVRkYNQWzy+zA1YY6G0RkIorCs4tQbsd6pteos1yIrm Jc4C4BxrpGG5K3JNSLWxnnHXUw7JQ== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id E28A2E49EC; Tue, 13 Nov 2018 11:06:44 -0500 (EST) From: Thomas Monjalon To: "Burdick, Cliff" Cc: "Burakov, Anatoly" , "dev@dpdk.org" Date: Tue, 13 Nov 2018 17:06:43 +0100 Message-ID: <7642123.6x7mORRspS@xps> In-Reply-To: <03A7D9A58FAFB54FBB01FEE199D7308A0134B8F187@wdc1exchmbxp02.hq.corp.viasat.com> References: <03A7D9A58FAFB54FBB01FEE199D7308A0134B8EE1F@wdc1exchmbxp02.hq.corp.viasat.com> <1fb8df6f-8056-5e79-1a77-e17b6383ca1c@intel.com> <03A7D9A58FAFB54FBB01FEE199D7308A0134B8F187@wdc1exchmbxp02.hq.corp.viasat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 16:06:46 -0000 13/11/2018 16:45, Burdick, Cliff: > From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com] > > On 13-Nov-18 9:21 AM, Thomas Monjalon wrote: > > > 13/11/2018 00:33, Burdick, Cliff: > > >> This patch was submitted by Jean Tourrilhes over two years ago, but > > >> didn't receive any responses. I hit the same issue recently when > > >> trying to use cgo (Golang) as a primary process linked to libdpdk.a > > >> against a C++ application linked against the same library.> > > > > > > > > The question is to know why you don't have the same constructors in > > > primary and seconday? > > > > I've hit similar things in the past. I believe it was caused by our build system stripping out unused libraries (such as rte_hash) from the binary and thus not calling the constructor in the primary, but doing so in the secondary (or something to that effect). > > In any case, this is caused by linking different number of libraries to primary and secondary, and should probably be fixed in the build system, not in the tailqs code (unless we specifically support having different linked libraries to primary and secondary?). > > Right, I think the original author of the patch stated the reasons in the link I provided. The build system seems like the most appropriate place to fix it, but the patch got me going quickly. I think the question is whether you want DPDK to support these other ways of linking. I'm certainly not the first to use cgo, since there's a virtual switch project doing the same: > > https://github.com/lagopus/vsw > > They don't use primary/secondary processes, though, so the issue is never hit. I'm in a situation where using cgo seemed like the easiest path to accomplish what I'm doing since I needed specialized libraries for it that were not available in C/C++. At some point I bet someone would use Cython to start linking against DPDK as well, and we'd likely run into the same issue. For sure, we want to support using DPDK with cgo or cython. But it is not clear what is the relation with not having the same compilation for primary and secondary. Please could you elaborate?