From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <prvs=0856881b6c=cliff.burdick@viasat.com> Received: from mta-us-central-03.viasat.com (mta-us-central-03.viasat.com [8.37.103.60]) by dpdk.org (Postfix) with ESMTP id EB3141B1ED for <dev@dpdk.org>; Wed, 14 Nov 2018 18:40:28 +0100 (CET) Received: from pps.filterd (wdc1mta02.viasat.com [127.0.0.1]) by wdc1mta02.viasat.com (8.16.0.22/8.16.0.22) with SMTP id wAEHaNjj015493; Wed, 14 Nov 2018 17:40:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viasat.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pp1; bh=MzbEqKgrmZOqyz1N976QOwRNvuJTOztZpBZJNGrsl+Y=; b=cIb7r2/HVIM8H3jg2p78K6tVtyazqfg4WYrb7E7Vn7IQ4RpZyj/kk/4KzwVv5YiSle2i SnIQbAjl0OBVWeKF4s2Wud8XTTAY/WrgXSiE2Dv/KQDLlddOigQ6w0VGEOkjQpgCvwX2 2hhxvzCNRjYHpukYoF0s109dr2C+fBGKTPSAPczqtvhioOlQfvprX8aFAaWQL9jbmx+k /nwabzobWVwt3Ufidvsz5eaO7d0n2rtUW0fu+EcirXZhzYc7CmyKdAROCXb2NYsOdLMr EvvJ++ytweuJEwh6qxmsr5IVicP1rcBAe5hHDgvPS6iUanwqE06i7jYn89SgNwtEu7YA QQ== From: "Burdick, Cliff" <Cliff.Burdick@viasat.com> To: Bruce Richardson <bruce.richardson@intel.com> CC: Thomas Monjalon <thomas@monjalon.net>, "Burakov, Anatoly" <anatoly.burakov@intel.com>, "dev@dpdk.org" <dev@dpdk.org> Thread-Topic: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs Thread-Index: AdR632/vnvJ3U124TOeqdBTRFJxhhAAjX12AAACgVoAAAhyMkAALanuAAA4AxoD//5prAIAAGvTAgABCZID//6GNj4ABQJ+AgAAVxfA= Date: Wed, 14 Nov 2018 17:40:25 +0000 Message-ID: <03A7D9A58FAFB54FBB01FEE199D7308A0134B8FA28@wdc1exchmbxp02.hq.corp.viasat.com> References: <03A7D9A58FAFB54FBB01FEE199D7308A0134B8EE1F@wdc1exchmbxp02.hq.corp.viasat.com> <2172258.pSIRIAPMh3@xps> <03A7D9A58FAFB54FBB01FEE199D7308A0134B8F4C4@wdc1exchmbxp02.hq.corp.viasat.com> <1843907.qCN5czUxPS@xps> <03A7D9A58FAFB54FBB01FEE199D7308A0134B8F564@wdc1exchmbxp02.hq.corp.viasat.com> <20181114114741.GA17424@bricha3-MOBL.ger.corp.intel.com> In-Reply-To: <20181114114741.GA17424@bricha3-MOBL.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-14_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=20 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811140159 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 14 Nov 2018 17:40:29 -0000 -----Original Message----- From: Bruce Richardson [mailto:bruce.richardson@intel.com]=20 Sent: Wednesday, November 14, 2018 3:48 AM To: Burdick, Cliff Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is= missing tailqs On Tue, Nov 13, 2018 at 11:42:51PM +0000, Burdick, Cliff wrote: > >=20 > > ________________________________________ > > From: Thomas Monjalon [thomas@monjalon.net] > > Sent: Tuesday, November 13, 2018 2:18 PM > > To: Burdick, Cliff > > Cc: Burakov, Anatoly; dev@dpdk.org; bruce.richardson@intel.com > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if=20 > > primary is missing tailqs > >=20 > > 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=20 > > > > > > > >> years ago, but didn't receive any responses. I hit the=20 > > > > > > > >> same issue recently when trying to use cgo (Golang) as a=20 > > > > > > > >> primary process linked to libdpdk.a against a C++=20 > > > > > > > >> application linked against the same library.> > > > > > > > > > > > > > > > > > > The question is to know why you don't have the same=20 > > > > > > > > constructors in primary and seconday? > > > > > > > > > > > > > > I've hit similar things in the past. I believe it was caused= =20 > > > > > > > by our build system stripping out unused libraries (such as=20 > > > > > > > rte_hash) from the binary and thus not calling the=20 > > > > > > > constructor in the primary, but doing so in the secondary=20 > > > > > > > (or something to that effect). In any case, this is caused=20 > > > > > > > by linking different number of libraries to primary and=20 > > > > > > > secondary, and should probably be fixed in the build system,= =20 > > > > > > > not in the tailqs code (unless we specifically support=20 > > > > > > > having different linked libraries to primary and=20 > > > > > > > secondary?).> > > > > > > > > > Right, I think the original author of the patch stated the=20 > > > > > > reasons in the link I provided. The build system seems like=20 > > > > > > the most appropriate place to fix it, but the patch got me=20 > > > > > > going quickly. I think the question is whether you want DPDK=20 > > > > > > to support these other ways of linking. I'm certainly not the=20 > > > > > > first to use cgo, since there's a virtual switch project doing = the same: > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.c= o > > > > > > m_lago > > > > > > pu > > > > > > s_vsw&d=3DDwICAg&c=3Djcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5= w&r > > > > > > =3Dm1RLQ > > > > > > OG > > > > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=3DhQqVCNwW7eoEzB_hLFK97i= 8 > > > > > > idS8FI qX=20 > > > > > > oPeclwsIZq7Y&s=3DBMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno4-SojKM&e= =3D > > > > > > > > > > > > They don't use primary/secondary processes, though, so the=20 > > > > > >issue is never hit. I'm in a situation where using cgo seemed=20 > > > > > >like the easiest path to accomplish what I'm doing since I=20 > > > > > >needed specialized libraries for it that were not available in= =20 > > > > > >C/C++. At some point I bet someone would use Cython to start=20 > > > > > >linking against DPDK as well, and we'd likely run into the=20 > > > > > >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=20 > > > > > >same compilation for primary and secondary. Please could you=20 > > > > > >elaborate?> > > > > > > > Hi Thomas, I think Jean explained it well here: > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__dev.dpdk.n= arkive. > > > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-2Dconstructors-2Dconsider > > > > > ed-2De=20 > > > > > vil&d=3DDwICAg&c=3Djcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r= =3Dm1R > > > > > LQOGOk=20 > > > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=3DC69wDgrjDX8_oXp1M_3bnmWOOZ= d > > > > > GqwBBG=20 > > > > > 9vzkyGDWGQ&s=3DYYn2N7WrzJpH1ptNrLZad0nPAQdrUyqBckk2uFuWYPQ&e=3D > > > > > > > > > > "The build system of the application does not have all the=20 > > > > > subtelties of the DPDK build system, and ends up including *all*= =20 > > > > > the constructors, wether they are used or not in the code.=20 > > > > > Moreover, they are included in a different order. Actually, by=20 > > > > > default the builds include no constructors at all (which is a=20 > > > > > big fail), so the library needs to be included with=20 > > > > > --whole-archive (see Snort DPDK instructions)." > > > > > > > > > > I will get to the bottom of my exact case to understand what's=20 > > > > > happening, but my primary application is a cgo application that=20 > > > > > I'm linking to by using almost exactly the same flags that are=20 > > > > > used in the DPDK build system to build examples. The DPDK=20 > > > > > libraries I'm linking against is a single location for both=20 > > > > > 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,=20 > > > > > which cgo can use, but I don't know if that ever was=20 > > > > > implemented. Cgo can use pkg-config if it's available, otherwise= =20 > > > > > 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 i= t is now implemented thanks to the meson build system: > > > > =20 > > > >https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__git.dpdk.org_d= p > > > >dk_tree_doc_build-2Dsdk-2Dmeson.txt-23n182&d=3DDwICAg&c=3Djcv3orpCsv= 7C4 > > > >ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=3Dm1RLQOGOkz9MauvVLZmiGtyWc5mA7Dejb= P > > > >FNE1IDj->4&m=3DC69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDWGQ&s=3DoC86K= D_R > > > >J1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=3D > > > > > > Hi Thomas, are there instructions on how to use pkg-config to build t= he 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. > >=20 > > > If the dependency is found, meson will enable the PMD when building D= PDK. > >=20 > > Do you know where exactly that is? I've been using mlx5 for a while on = this system, and I can see that 18.11-rc2 meson build+ninja built the pmd, = but it's not on the --libs listing for pkg-config. Does it tell me what I w= as missing? > >=20 > For dynamic linking of applications, the drivers are not normally linked = in. Instead, they should be loaded from the drivers directory as .so files > - normally by default in EAL as the driver .so's should be copied to the = EAL_PMD_PATH where EAL finds them automatically. [This applies to both meso= n and make builds, though only meson generates the .pc file for pkg-config] >=20 > If you are doing a static build, then you need to explicitly link in the = drivers. You can get a list from pkg-config using the "--static" flag in th= is case. A good example of how to use pkg-config in this way can be found i= n the Makefiles for most examples, e.g. examples/helloworld/Makefile, repro= duced below. >=20 > Regards, > /Bruce >=20 > all: shared > .PHONY: shared static > shared: build/$(APP)-shared > ln -sf $(APP)-shared build/$(APP) > static: build/$(APP)-static > ln -sf $(APP)-static build/$(APP) >=20 > PC_FILE :=3D $(shell pkg-config --path libdpdk) CFLAGS +=3D -O3 $(shell p= kg-config --cflags libdpdk) LDFLAGS_SHARED =3D $(shell pkg-config --libs li= bdpdk) LDFLAGS_STATIC =3D -Wl,-Bstatic $(shell pkg-config --static --libs l= ibdpdk) >=20 > build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build > $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_SHARED) >=20 > build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build > $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_STATIC) >=20 > build: > @mkdir -p $@ Thanks Bruce. I tried getting this to compile using cgo, and it's causing m= ore pain than it's worth. I used the --static --libs options, and there wer= e still numerous linker errors, some specific to mlx, and some not. Specifi= cally libmlx5 and libmnl are both needed, but they're not part of the linke= r line from pkg-config. At this point I'll just break the Go application up= into a separate C application that handles all the DPDK parts, and send me= ssages between them.