From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 7FBF84CA5 for ; Thu, 15 Nov 2018 17:41:21 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2018 08:41:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,236,1539673200"; d="scan'208";a="86115892" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.107]) by fmsmga007.fm.intel.com with SMTP; 15 Nov 2018 08:41:17 -0800 Received: by (sSMTP sendmail emulation); Thu, 15 Nov 2018 16:41:17 +0000 Date: Thu, 15 Nov 2018 16:41:16 +0000 From: Bruce Richardson To: "Burdick, Cliff" Cc: Luca Boccassi , Thomas Monjalon , "Burakov, Anatoly" , "dev@dpdk.org" Message-ID: <20181115164116.GA5012@bricha3-MOBL.ger.corp.intel.com> References: <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> <03A7D9A58FAFB54FBB01FEE199D7308A0134B8FA28@wdc1exchmbxp02.hq.corp.viasat.com> <1542219312.11515.15.camel@debian.org> <03A7D9A58FAFB54FBB01FEE199D7308A0134B8FB80@wdc1exchmbxp02.hq.corp.viasat.com> <1542274397.11515.18.camel@debian.org> <03A7D9A58FAFB54FBB01FEE199D7308A0134B905F7@wdc1exchmbxp02.hq.corp.viasat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <03A7D9A58FAFB54FBB01FEE199D7308A0134B905F7@wdc1exchmbxp02.hq.corp.viasat.com> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.10.1 (2018-07-13) 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: Thu, 15 Nov 2018 16:41:22 -0000 On Thu, Nov 15, 2018 at 04:15:36PM +0000, Burdick, Cliff wrote: >=20 >=20 > -----Original Message----- > From: Luca Boccassi [mailto:bluca@debian.org]=20 > Sent: Thursday, November 15, 2018 1:33 AM > To: Burdick, Cliff; Bruce Richardson > 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 >=20 > > On Wed, 2018-11-14 at 18:24 +0000, Burdick, Cliff wrote: > > >=20 > > > -----Original Message----- > > > From: Luca Boccassi [mailto:bluca@debian.org] > > > Sent: Wednesday, November 14, 2018 10:15 AM > > > To: Burdick, Cliff; Bruce Richardson > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if=20 > > > primary is missing tailqs > > >=20 > > > > On Wed, 2018-11-14 at 17:40 +0000, Burdick, Cliff wrote: > > > > >=20 > > > > > -----Original Message----- > > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > > > > 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= =20 > > > > > primary is missing tailqs > > > > >=20 > > > > > 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.co= =20 > > > > > > > m > > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary= =20 > > > > > > > if 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 ove= r=20 > > > > > > > > > > > > > > two years ago, but didn't receive any responses= =2E=20 > > > > > > > > > > > > > > I hit the same issue recently when trying to us= e=20 > > > > > > > > > > > > > > cgo > > > > > > > > > > > > > > (Golang) as a primary process linked to=20 > > > > > > > > > > > > > > libdpdk.a against a C++ application linked=20 > > > > > > > > > > > > > > against the same library.> > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > The question is to know why you don't have the=20 > > > > > > > > > > > > > same constructors in primary and seconday? > > > > > > > > > > > >=20 > > > > > > > > > > > > I've hit similar things in the past. I believe it= =20 > > > > > > > > > > > > was caused by our build system stripping out unused= =20 > > > > > > > > > > > > libraries (such as > > > > > > > > > > > > rte_hash) from the binary and thus not calling the= =20 > > > > > > > > > > > > constructor in the primary, but doing so in the=20 > > > > > > > > > > > > secondary (or something to that effect). In any=20 > > > > > > > > > > > > case, this is caused by linking different number of= =20 > > > > > > > > > > > > libraries to primary and secondary, and should=20 > > > > > > > > > > > > probably be fixed in the build system, not in the= =20 > > > > > > > > > > > > tailqs code (unless we specifically support having= =20 > > > > > > > > > > > > different linked libraries to primary and=20 > > > > > > > > > > > > secondary?).> > > > > > > > > > > > > > >=20 > > > > > > > > > > > Right, I think the original author of the patch state= d=20 > > > > > > > > > > > the reasons in the link I provided. The build system= =20 > > > > > > > > > > > seems like the most appropriate place to fix it, but= =20 > > > > > > > > > > > the patch got me going quickly. I think the question= =20 > > > > > > > > > > > is whether you want DPDK to support these other ways= =20 > > > > > > > > > > > of linking. > > > > > > > > > > > I'm > > > > > > > > > > > certainly not the first to use cgo, since there's a= =20 > > > > > > > > > > > virtual switch project doing the same: > > > > > > > > > > >=20 > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A= __ > > > > > > > > > > > gith > > > > > > > > > > > ub.co > > > > > > > > > > > m_lago > > > > > > > > > > > pu > > > > > > > > > > > s_vsw&d=3DDwICAg&c=3Djcv3orpCsv7C4ly8- > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r =3Dm1RLQ OG > > > > > > > > > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj- > > > > > > > > > > > 4&m=3DhQqVCNwW7eoEzB_hLFK97i8 idS8FI qX > > > > > > > > > > > oPeclwsIZq7Y&s=3DBMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno= 4- > > > > > > > > > > > SojKM&e=3D > > > > > > > > > > >=20 > > > > > > > > > > > They don't use primary/secondary processes, though, s= o=20 > > > > > > > > > > > the issue is never hit. I'm in a situation where=20 > > > > > > > > > > > using cgo seemed like the easiest path to accomplish= =20 > > > > > > > > > > > what I'm doing since I needed specialized libraries= =20 > > > > > > > > > > > for it that were not available in C/C++. At some poin= t=20 > > > > > > > > > > > I bet someone would use Cython to start linking=20 > > > > > > > > > > > against DPDK as well, and we'd likely run into the= =20 > > > > > > > > > > > same issue.> > > > For sure, we want to support using= =20 > > > > > > > > > > > DPDK with cgo or cython. > > > > > > > > > > > But it is not clear what is the relation with not=20 > > > > > > > > > > > having the same compilation for primary and secondary. > > > > > > > > > > > Please > > > > > > > > > > > could you elaborate?> > > > > > > > > > > > >=20 > > > > > > > > > > Hi Thomas, I think Jean explained it well here: > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= de > > > > > > > > > > v.dp > > > > > > > > > > dk.narkive. > > > > > > > > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-2Dconstructors- > > > > > > > > > > 2Dconsider > > > > > > > > > > ed-2De > > > > > > > > > > vil&d=3DDwICAg&c=3Djcv3orpCsv7C4ly8-=20 > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=3Dm1R LQOGOk > > > > > > > > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-=20 > > > > > > > > > > 4&m=3DC69wDgrjDX8_oXp1M_3bnmWOOZd GqwBBG=20 > > > > > > > > > > 9vzkyGDWGQ&s=3DYYn2N7WrzJpH1ptNrLZad0nPAQdrUyqBckk2uFuW= YP > > > > > > > > > > Q&e=3D > > > > > > > > > >=20 > > > > > > > > > > "The build system of the application does not have all= =20 > > > > > > > > > > the subtelties of the DPDK build system, and ends up=20 > > > > > > > > > > including > > > > > > > > > > *all* > > > > > > > > > > the constructors, wether they are used or not in the=20 > > > > > > > > > > code. > > > > > > > > > > Moreover, they are included in a different order. > > > > > > > > > > Actually, > > > > > > > > > > by default the builds include no constructors at all=20 > > > > > > > > > > (which is a big fail), so the library needs to be=20 > > > > > > > > > > included with --whole-archive (see Snort DPDK=20 > > > > > > > > > > instructions)." > > > > > > > > > >=20 > > > > > > > > > > I will get to the bottom of my exact case to understand= =20 > > > > > > > > > > what's happening, but my primary application is a cgo= =20 > > > > > > > > > > application that I'm linking to by using almost exactly= =20 > > > > > > > > > > the same flags that are used in the DPDK build system t= o=20 > > > > > > > > > > build examples. The DPDK libraries I'm linking against= =20 > > > > > > > > > > is a single location for both primary and secondary; in= =20 > > > > > > > > > > other words, I don't build DPDK twice. > > > > > > > > > >=20 > > > > > > > > > > OK I understand, thanks. > > > > > > > > > >=20 > > > > > > > > > > You had alluded to a pkg-config for DPDK in the 2015=20 > > > > > > > > > > thread, which cgo can use, but I don't know if that eve= r=20 > > > > > > > > > > was implemented. Cgo can use pkg-config if it's=20 > > > > > > > > > > available, otherwise the only tools are specifying=20 > > > > > > > > > > LDFLAGS and CFLAGS into their build system. > > > > > > > > >=20 > > > > > > > > > Yes, the right answer is still pkg-config :) The good new= s=20 > > > > > > > > > is that it is now implemented thanks to the meson build > > > > > > > > > system: > > > > > > > > > =20 > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__git= =2Ed > > > > > > > > > pdk. > > > > > > > > > org_dp > > > > > > > > > dk_tree_doc_build-2Dsdk-2Dmeson.txt- > > > > > > > > > 23n182&d=3DDwICAg&c=3Djcv3orpCsv7C4 > > > > > > > > > ly8- > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=3Dm1RLQOGOkz9MauvVLZmiGtyWc5= mA > > > > > > > > > 7Dej > > > > > > > > > bP > > > > > > > > > FNE1IDj- > > > > > > > > > > 4&m=3DC69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDWGQ&s=3Do= C86K > > > > > > > > > > D_R > > > > > > > > >=20 > > > > > > > > > J1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=3D > > > > > > > >=20 > > > > > > > > Hi Thomas, are there instructions on how to use pkg-config= =20 > > > > > > > > to build the mlx4/5 PMD? I noticed a patch was submitted in= =20 > > > > > > > > September to add support for it, but that link you provided= =20 > > > > > > > > on using meson doesn't say how to build specific drivers. I= t=20 > > > > > > > > appears to be disabled by default. > > > > > > > > If the dependency is found, meson will enable the PMD when= =20 > > > > > > > > building DPDK. > > > > > > >=20 > > > > > > > Do you know where exactly that is? I've been using mlx5 for a= =20 > > > > > > > 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 was missing? > > > > > > >=20 > > > > > >=20 > > > > > > For dynamic linking of applications, the drivers are not=20 > > > > > > normally linked in. Instead, they should be loaded from the=20 > > > > > > drivers directory as .so files > > > > > > - normally by default in EAL as the driver .so's should be=20 > > > > > > copied to the EAL_PMD_PATH where EAL finds them automatically.= =20 > > > > > > [This applies to both meson and make builds, though only meson= =20 > > > > > > generates the .pc file for pkg-config] > > > > > >=20 > > > > > > If you are doing a static build, then you need to explicitly=20 > > > > > > link in the drivers. You can get a list from pkg-config using= =20 > > > > > > the " > > > > > > --static" flag in this case. A good example of how to use pkg-= =20 > > > > > > config in this way can be found in the Makefiles for most=20 > > > > > > examples, e.g. examples/helloworld/Makefile, reproduced 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= =20 > > > > > > $(shell pkg-config --cflags libdpdk) LDFLAGS_SHARED =3D $(shell= =20 > > > > > > pkg- config -- libs libdpdk) LDFLAGS_STATIC =3D -Wl,-Bstatic=20 > > > > > > $(shell pkg-config > > > > > > -- > > > > > > static --libs libdpdk) > > > > > >=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 $@ > > > > >=20 > > > > > Thanks Bruce. I tried getting this to compile using cgo, and it's= =20 > > > > > causing more pain than it's worth. I used the --static --libs=20 > > > > > options, and there were still numerous linker errors, some=20 > > > > > specific to mlx, and some not. Specifically libmlx5 and libmnl ar= e=20 > > > > > both needed, but they're not part of the linker line from=20 > > > > > pkg-config. At this point I'll just break the Go application up= =20 > > > > > into a separate C application that handles all the DPDK parts, an= d=20 > > > > > send messages between them. > > > >=20 > > > > Hi, > > > >=20 > > > > As far as I can see, both mnl and mlx5 (and all the other reverse > > > > dependencies) are listed correctly in the libdpdk.pc Libs.private= =20 > > > > entry, and pkg-config --libs --static libdpdk.pc does print them as= =20 > > > > intended. This is with 18.11-rc3. > > > > Are you sure everything is correct (pkg-config path is right, --=20 > > > > static is used, etc)? > > > >=20 > > > > -- > > > > Kind regards, > > > > Luca Boccassi > > >=20 > > > Hi Luca, here is what pkg-config gives: > > >=20 > > > PKG_CONFIG_PATH=3Dmeson-private/ pkg-config --libs --static libdpdk= =20 > > > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev -lrte_power=20 > > > -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal -lrte_pipeline=20 > > > -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics=20 > > > -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring -lrte_mempool=20 > > > -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf -lrte_kvargs= =20 > > > -lrte_port -lrte_pci -lrte_ethdev -lrte_gro -lrte_gso -lrte_cryptodev= =20 > > > -lrte_sched -lrte_latencystats -lrte_efd -lrte_distributor -lrte_mete= r=20 > > > -lrte_acl -lrte_member -lrte_cmdline -lrte_lpm -lrte_kni -lrte_cfgfil= e=20 > > > -lrte_bitratestats -lrte_timer -lrte_flow_classify=20 > > > -lrte_mempool_bucket -lrte_pmd_null_crypto -lrte_pmd_failsafe=20 > > > -lrte_bus_ifpga -lrte_pmd_atlantic -lrte_pmd_mlx4 -lrte_pmd_vmxnet3= =20 > > > -lrte_pmd_avp -lrte_common_dpaax -lrte_pmd_ena -lcrypto=20 > > > -lrte_bus_fslmc -ldl -lrte_pmd_avf -lrte_pmd_crypto_scheduler=20 > > > -lrte_pmd_netvsc -lrte_pmd_vhost -lrte_bus_dpaa -lrte_mempool_dpaa2= =20 > > > -lrte_common_octeontx -lrte_pmd_liquidio -lrte_pmd_ifc -Wl,-Bdynamic= =20 > > > -lnuma -lrte_pmd_enic -lrte_common_cpt -pthread=20 > > > -lrte_pmd_octeontx_crypto -lrte_pmd_qat -lrte_bus_vmbus -lrte_pmd_nul= l=20 > > > -lm -lrte_pmd_dpaa -lrte_bus_vdev -lrte_pmd_dpaa2=20 > > > -lrte_pmd_skeleton_event -lrte_pmd_af_packet -lrte_pmd_octeontx=20 > > > -lrte_pmd_thunderx -lrte_pmd_ring -lrte_pmd_octeontx_event=20 > > > -lrte_pmd_sw_event -lrte_pmd_ark -lrte_mempool_octeontx=20 > > > -lrte_pmd_ixgbe -lrte_pmd_kni -lrte_mempool_ring=20 > > > -lrte_pmd_virtio_crypto -lrte_mempool_dpaa -lrte_pmd_dpaa2_cmdif=20 > > > -lrte_bus_pci -lrte_pmd_opdl_event -lrte_pmd_mlx5 -lrte_pmd_virtio=20 > > > -lrte_pmd_tap -lrte_pmd_caam_jr -lrte_pmd_dpaa2_sec=20 > > > -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc -lrte_pmd_sfc -lrte_pmd_bnxt=20 > > > -lrte_pmd_dpaa2_event -lrte_pmd_cxgbe -Wl,--whole-archive -Wl,--no-= =20 > > > as-needed -lrte_pmd_e1000 -lrte_pmd_softnic -lrte_pmd_bond=20 > > > -lrte_pmd_fm10k -lrte_pmd_i40e -lrte_pmd_nfp -lrte_pmd_qede -Wl,--no-= =20 > > > whole-archive -lrte_pmd_axgbe -lrte_pmd_ccp -lrte_pmd_ifpga_rawdev=20 > > > -lrte_pmd_bbdev_null -lrte_pmd_openssl -lrte_pmd_dsw_event=20 > > > -lrte_pmd_dpaa_event -lrte_mempool_stack -lrte_pmd_vdev_netvsc=20 > > > -lrte_pmd_dpaa_sec -lrte_pmd_skeleton_rawdev=20 > > > -lrte_pmd_octeontx_compress > > >=20 > > > You'll notice there's no mlx5 or mnl in that list. I was using 18.11- > > > rc2 since I cloned early yesterday. Perhaps meson determined not to= =20 > > > put it in there for some reason? > >=20 > > Were mlx5/mnl found at meson configure time? > >=20 > > -- > > Kind regards, > > Luca Boccassi >=20 > Hi Luca, yes, it was: >=20 > Library mnl found: YES > Library mlx4 found: YES > Library ibverbs found: YES > Compiler for C supports argument -Wextra: YES > Compiler for C supports argument -std=3Dc11: YES > Compiler for C supports argument -Wno-strict-prototypes: YES > Compiler for C supports argument -D_BSD_SOURCE: YES > Compiler for C supports argument -D_DEFAULT_SOURCE: YES > Compiler for C supports argument -D_XOPEN_SOURCE=3D600: YES > Checking whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size"= : YES > Configuring mlx4_autoconf.h using configuration > Library mnl found: YES > Library mlx5 found: YES > Library ibverbs found: YES > ... > PKG_CONFIG_PATH=3Dmeson-private/ pkg-config --libs --static libdpdk > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev -lrte_power -lrte_ip_fra= g -lrte_hash -lrte_pdump -lrte_eal -lrte_pipeline -lrte_table -lrte_bbdev -= lrte_bpf -lrte_vhost -lrte_metrics -lrte_jobstats -lrte_net -lrte_reorder -= lrte_ring -lrte_mempool -lrte_security -lrte_compressdev -lrte_rawdev -lrte= _mbuf -lrte_kvargs -lrte_port -lrte_pci -lrte_ethdev -lrte_gro -lrte_gso -l= rte_cryptodev -lrte_sched -lrte_latencystats -lrte_efd -lrte_distributor -l= rte_meter -lrte_acl -lrte_member -lrte_cmdline -lrte_lpm -lrte_kni -lrte_cf= gfile -lrte_bitratestats -lrte_timer -lrte_flow_classify -lrte_pmd_ccp -lrt= e_mempool_bucket -lrte_pmd_failsafe -lrte_pmd_netvsc -lrte_pmd_null_crypto = -lrte_bus_ifpga -lrte_pmd_atlantic -lrte_pmd_octeontx_event -lrte_pmd_avp -= lrte_pmd_mlx4 -lrte_common_dpaax -lrte_pmd_skeleton_rawdev -lrte_pmd_ena -l= rte_pmd_opdl_event -lrte_bus_fslmc -lnuma -lrte_pmd_avf -lrte_pmd_crypto_sc= heduler -lrte_pmd_vhost -lrte_bus_dpaa -lrte_mempool_dpaa2 -lrte_common_oct= eontx -Wl,--no-as-needed -lcrypto -lrte_pmd_ifc -lrte_pmd_liquidio -lrte_pm= d_enic -lrte_common_cpt -Wl,--no-whole-archive -lrte_bus_vmbus -lrte_pmd_oc= teontx_crypto -lrte_pmd_qat -lrte_pmd_ifpga_rawdev -lrte_pmd_dpaa -lrte_bus= _vdev -lrte_pmd_bbdev_null -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event -lrte_p= md_ring -lrte_pmd_af_packet -lrte_pmd_thunderx -lrte_pmd_dpaa_event -lrte_p= md_octeontx_compress -lrte_pmd_dpaa_sec -lrte_pmd_sw_event -Wl,--whole-arch= ive -lrte_pmd_ark -lrte_mempool_octeontx -lrte_pmd_ixgbe -lrte_mempool_ring= -lrte_pmd_kni -lrte_pmd_vmxnet3 -lrte_mempool_dpaa -lrte_bus_pci -lrte_pmd= _dpaa2_cmdif -lrte_pmd_mlx5 -lrte_pmd_tap -lrte_pmd_caam_jr -lrte_pmd_dpaa2= _sec -lm -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc -lrte_pmd_virtio -lrte_pmd_bn= xt -lrte_pmd_dpaa2_event -lrte_pmd_sfc -lrte_pmd_cxgbe -pthread -lrte_pmd_e= 1000 -lrte_pmd_softnic -ldl -lrte_pmd_null -lrte_pmd_bond -lrte_pmd_fm10k -= lrte_pmd_i40e -lrte_pmd_nfp -lrte_pmd_qede -lrte_pmd_axgbe -Wl,-Bdynamic -l= rte_pmd_openssl -lrte_pmd_octeontx -lrte_pmd_dsw_event -lrte_mempool_stack = -lrte_pmd_virtio_crypto -lrte_pmd_vdev_netvsc Is this with latest DPDK from git? because I see the exact same as Luca: $ PKG_CONFIG_PATH=3Dbuild/meson-private/ pkg-config --libs --static libdpdk= | grep mlx -L/usr/local/lib64 -lrte_telemetry -lrte_bpf -lrte_flow_classify -lrte_pipe= line -lrte_table -lrte_port -lrte_vhost -lrte_security -lrte_sched -lrte_re= order -lrte_rawdev -lrte_pdump -lrte_power -lrte_meter -lrte_member -lrte_l= pm -lrte_latencystats -lrte_kni -lrte_jobstats -lrte_ip_frag -lrte_gso -lrt= e_gro -lrte_eventdev -lrte_efd -lrte_distributor -lrte_cryptodev -lrte_comp= ressdev -lrte_cfgfile -lrte_bitratestats -lrte_bbdev -lrte_acl -lrte_timer = -lrte_hash -lrte_metrics -lrte_pci -lrte_ethdev -lrte_net -lrte_mbuf -lrte_= mempool -lrte_ring -lrte_eal -lrte_kvargs -lrte_cmdline -L/usr/local/lib64 = -lrte_kvargs -lrte_eal -lrte_ring -lrte_mempool -lrte_mbuf -lrte_pci -lrte_= cryptodev -lrte_net -lrte_cmdline -lrte_ethdev -lrte_hash -lrte_timer -lrte= _common_dpaax -lrte_eventdev -lrte_rawdev -lrte_bus_dpaa -lrte_bus_fslmc -l= rte_bus_pci -lrte_common_octeontx -lrte_bus_vdev -lrte_meter -lrte_sched -l= rte_ip_frag -lz -lrte_mempool_dpaa -lrte_mempool_dpaa2 -lrte_vhost -lrte_se= curity -lrte_kni -lmnl -lmlx4 -libverbs -lmnl -lmlx5 -libverbs -lrte_bus_vm= bus -lrte_mempool_octeontx -lpcap -lrte_port -lrte_lpm -lrte_acl -lrte_tabl= e -lrte_pipeline -lsze2 -lrte_gso -lIPSec_MB -lIPSec_MB -lrte_common_cpt -l= rte_reorder -lrte_compressdev -lrte_pmd_dpaa -lrte_pmd_dpaa2 -lrte_pmd_dpaa= 2_sec -lrte_pmd_octeontx -lrte_bbdev -lrte_bus_ifpga -Wl,--whole-archive -l= rte_mempool_bucket -lrte_mempool_ring -lrte_mempool_stack -lrte_pmd_af_pack= et -lrte_pmd_ark -lrte_pmd_atlantic -lrte_pmd_avf -lrte_pmd_avp -lrte_pmd_a= xgbe -lrte_pmd_bond -lrte_pmd_bnx2x -lrte_pmd_bnxt -lrte_pmd_cxgbe -lrte_pm= d_e1000 -lrte_pmd_ena -lrte_pmd_enetc -lrte_pmd_enic -lrte_pmd_failsafe -lr= te_pmd_fm10k -lrte_pmd_i40e -lrte_pmd_ifc -lrte_pmd_ixgbe -lrte_pmd_kmod -l= rte_pmd_kni -lrte_pmd_liquidio -lrte_pmd_mlx4 -lrte_pmd_mlx5 -lrte_pmd_netv= sc -lrte_pmd_nfp -lrte_pmd_null -lrte_pmd_pcap -lrte_pmd_qede -lrte_pmd_rin= g -lrte_pmd_sfc -lrte_pmd_softnic -lrte_pmd_szedata2 -lrte_pmd_tap -lrte_pm= d_thunderx -lrte_pmd_vdev_netvsc -lrte_pmd_vhost -lrte_pmd_virtio -lrte_pmd= _vmxnet3 -lrte_pmd_aesni_gcm -lrte_pmd_aesni_mb -lrte_pmd_caam_jr -lrte_pmd= _ccp -lrte_pmd_dpaa_sec -lrte_pmd_null_crypto -lrte_pmd_octeontx_crypto -lr= te_pmd_openssl -lrte_pmd_crypto_scheduler -lrte_pmd_virtio_crypto -lrte_pmd= _octeontx_compress -lrte_pmd_qat -lrte_pmd_zlib -lrte_pmd_dpaa_event -lrte_= pmd_dpaa2_event -lrte_pmd_octeontx_event -lrte_pmd_opdl_event -lrte_pmd_ske= leton_event -lrte_pmd_sw_event -lrte_pmd_dsw_event -lrte_pmd_bbdev_null -lr= te_pmd_skeleton_rawdev -lrte_pmd_dpaa2_cmdif -lrte_pmd_dpaa2_qdma -lrte_pmd= _ifpga_rawdev -lrte_pmd_ioat_copy -Wl,--no-whole-archive -Wl,-Bdynamic -Wl,= --no-as-needed -pthread -lm -ldl -lnuma -lbsd -lpcap -lcrypto -lcrypto -lz = -lcrypto -ldl -pthread -lz