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 76182201 for ; Tue, 13 Nov 2018 23:18:14 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 06CB920D2B; Tue, 13 Nov 2018 17:18:14 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 13 Nov 2018 17:18:14 -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=v4pkkrMY4TLUfVpRPyt/bqzuyOsOfd2xOE3Su0ECAx0=; b=hy64Bgtyv158 SzIAHOMVR5FtLD+cy61EKU5MS1W11d4SpEvzTOOFdKfHF/c0D13nJxG7G11E1z9i Lwqc5aJ5JcZn00/5dmvly+qVzZmSTHyFoTF6v2SC11RRRbCF4Ba/+WV2eh2dygH0 me30q7oWx+MdWXy9dMSnZT/s8QMeC6M= 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=v4pkkrMY4TLUfVpRPyt/bqzuyOsOfd2xOE3Su0ECA x0=; b=rF7RkU8Q8NxAKYNh2uONaodUCYco7VRLGZQ/nOsSA+EZjqIzlFcPJWyI2 O3JwQOo90/frHJ9IOuGo23o2yE9JCEivd1zlP7jD1NOVRfiB8AyhS+UeEZEnfJ1U l491Tboe3o/QcIvwEd/15tbXt5oF+2bThDOTOl5F96fSIYFxf9ckK3Wk5dTDJelw wrwzNeLvpcNIEaciIXB5Sv28QIOJVU9TmYqpI/iRAHPAwU82Qb5cQcojIlTknivy 1upSjGljDCKZcVJ+Ags81Lws7rDweaY0f478DexCFfITD33cOP03ndYyW52Yx5ei Z6Gy8rPSVBfir9wIE1l6P3Q+CnT0w== 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 B715B102DD; Tue, 13 Nov 2018 17:18:12 -0500 (EST) From: Thomas Monjalon To: "Burdick, Cliff" Cc: "Burakov, Anatoly" , "dev@dpdk.org" , "bruce.richardson@intel.com" Date: Tue, 13 Nov 2018 23:18:11 +0100 Message-ID: <1843907.qCN5czUxPS@xps> In-Reply-To: <03A7D9A58FAFB54FBB01FEE199D7308A0134B8F4C4@wdc1exchmbxp02.hq.corp.viasat.com> References: <03A7D9A58FAFB54FBB01FEE199D7308A0134B8EE1F@wdc1exchmbxp02.hq.corp.viasat.com> <2172258.pSIRIAPMh3@xps> <03A7D9A58FAFB54FBB01FEE199D7308A0134B8F4C4@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 22:18:14 -0000 13/11/2018 23:08, Burdick, Cliff: > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > 13/11/2018 17:38, Burdick, Cliff: > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_lago > > > > pu > > > > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQ > > > > OG > > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=hQqVCNwW7eoEzB_hLFK97i8idS8FI > > > > qX oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno4-SojKM&e= > > > > > > > > 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?> > > > > > Hi Thomas, I think Jean explained it well here: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.dpdk.narkive. > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-2Dconstructors-2Dconsidered-2De > > > vil&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOk > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG > > > 9vzkyGDWGQ&s=YYn2N7WrzJpH1ptNrLZad0nPAQdrUyqBckk2uFuWYPQ&e= > > > > > > "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 will get to the bottom of my exact case to understand what's > > > happening, but my primary application is a cgo application that I'm > > > linking to by using almost exactly the same flags that are used in the > > > DPDK build system to build examples. The DPDK libraries I'm linking > > > against is a single location for both primary and secondary; in other > > > words, I don't build DPDK twice. > > > > > > OK I understand, thanks. > > > > > > You had alluded to a pkg-config for DPDK in the 2015 thread, which cgo > > > can use, but I don't know if that ever was implemented. Cgo can use > > > pkg-config if it's available, otherwise the only tools are specifying > > > LDFLAGS and CFLAGS into their build system. > >Yes, the right answer is still pkg-config :) The good news is that it is now implemented thanks to the meson build system: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.dpdk.org_dpdk_tree_doc_build-2Dsdk-2Dmeson.txt-23n182&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOkz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj->4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDWGQ&s=oC86KD_RJ1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e= > > Hi Thomas, are there instructions on how to use pkg-config to build the mlx4/5 PMD? I noticed a patch was submitted in September to add support for it, but that link you provided on using meson doesn't say how to build specific drivers. It appears to be disabled by default. If the dependency is found, meson will enable the PMD when building DPDK.