From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by dpdk.org (Postfix) with ESMTP id 00AAE4C92 for ; Thu, 15 Nov 2018 10:33:20 +0100 (CET) Received: by mail-wr1-f65.google.com with SMTP id v18-v6so20385819wrt.8 for ; Thu, 15 Nov 2018 01:33:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:mime-version; bh=yqRvxEs30fKYMgkdVraf9s/5/i0eB1AHH3nNTQxqjS8=; b=npteTNCEbXUiXNeoK6QFKRdMNoJo52KiEbJVJXJ67uH9mhzPktPuTFJF4h8DBE7yWS mqntQ5ttkyH9ifSp2V0DHc+xszFf2Gxd7Vqws8Odeo5cbtx4biXESHnXlalgbIPmSGPn MJ2Mf6Vfxftg6btdl0odsxMaSbyVsIMz+zxyfK7Tw2TyFr14gKx+D+8G/FXX/Ion5FYI z6xPCFIV/zMGPHI6XKz2ntYxZPKKAn9rTtBaXAvbq2LnTKtJOjO8RwZIYKw5Guf8PgrI RKyFZ3XZGz6CBmQbyQCLlqdKP45XHeaY07nNwzR401H6oYqTaNbsIvQITTUp85xWnuGw 4S9Q== X-Gm-Message-State: AA+aEWb6+md0KTkFpAQDhmW5c0iW6r5VMctiF391+Mqf2+lQs14Uf95w rVGxSualb8rZjXC2TM9xy7bC04n0 X-Google-Smtp-Source: AFSGD/XMDWb6csHEfxbfMlSKawcNs1OOGn8omGfMxfG2acC4eE9VEteMD0JrVRFSrTKQjFJBC89ifQ== X-Received: by 2002:adf:e50c:: with SMTP id j12mr2219702wrm.330.1542274400285; Thu, 15 Nov 2018 01:33:20 -0800 (PST) Received: from localhost ([2a01:4b00:f419:6f00:8361:8946:ba2b:d556]) by smtp.gmail.com with ESMTPSA id t187-v6sm15437867wmt.45.2018.11.15.01.33.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 15 Nov 2018 01:33:19 -0800 (PST) Message-ID: <1542274397.11515.18.camel@debian.org> From: Luca Boccassi To: "Burdick, Cliff" , Bruce Richardson Cc: Thomas Monjalon , "Burakov, Anatoly" , "dev@dpdk.org" Date: Thu, 15 Nov 2018 09:33:17 +0000 In-Reply-To: <03A7D9A58FAFB54FBB01FEE199D7308A0134B8FB80@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> <03A7D9A58FAFB54FBB01FEE199D7308A0134B8FA28@wdc1exchmbxp02.hq.corp.viasat.com> <1542219312.11515.15.camel@debian.org> <03A7D9A58FAFB54FBB01FEE199D7308A0134B8FB80@wdc1exchmbxp02.hq.corp.viasat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 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 09:33:21 -0000 On Wed, 2018-11-14 at 18:24 +0000, Burdick, Cliff wrote: >=20 > -----Original Message----- > From: Luca Boccassi [mailto:bluca@debian.org]=C2=A0 > 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 > 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=C2= =A0 > > > 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 > > > > > m > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary > > > > > if=C2=A0 > > > > > 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=C2=A0 > > > > > > > > > > > > years ago, but didn't receive any responses. I > > > > > > > > > > > > hit=C2=A0 > > > > > > > > > > > > the same issue recently when trying to use cgo=C2= =A0 > > > > > > > > > > > > (Golang) as a primary process linked to > > > > > > > > > > > > libdpdk.a=C2=A0 > > > > > > > > > > > > against a C++ application linked against the > > > > > > > > > > > > same=C2=A0 > > > > > > > > > > > > library.> > > > > > > > > > > > > >=20 > > > > > > > > > > > The question is to know why you don't have the > > > > > > > > > > > same=C2=A0 > > > > > > > > > > > constructors in primary and seconday? > > > > > > > > > >=20 > > > > > > > > > > I've hit similar things in the past. I believe it > > > > > > > > > > was=C2=A0 > > > > > > > > > > caused by our build system stripping out unused=C2=A0 > > > > > > > > > > libraries (such as > > > > > > > > > > rte_hash) from the binary and thus not calling the=C2= =A0 > > > > > > > > > > constructor in the primary, but doing so in the=C2=A0 > > > > > > > > > > secondary (or something to that effect). In any > > > > > > > > > > case,=C2=A0 > > > > > > > > > > this is caused by linking different number of > > > > > > > > > > libraries=C2=A0 > > > > > > > > > > to primary and secondary, and should probably be > > > > > > > > > > fixed=C2=A0 > > > > > > > > > > in the build system, not in the tailqs code (unless > > > > > > > > > > we=C2=A0 > > > > > > > > > > specifically support having different linked > > > > > > > > > > libraries=C2=A0 > > > > > > > > > > to primary and secondary?).> > > > > > > > > > > > >=20 > > > > > > > > > Right, I think the original author of the patch > > > > > > > > > stated the=C2=A0 > > > > > > > > > reasons in the link I provided. The build system > > > > > > > > > seems=C2=A0 > > > > > > > > > like the most appropriate place to fix it, but the > > > > > > > > > patch=C2=A0 > > > > > > > > > got me going quickly. I think the question is whether > > > > > > > > > you=C2=A0 > > > > > > > > > want DPDK to support these other ways of linking. > > > > > > > > > I'm=C2=A0 > > > > > > > > > certainly not the first to use cgo, since there's a=C2=A0 > > > > > > > > > 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=3DBMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno4- > > > > > > > > > SojKM&e=3D > > > > > > > > >=20 > > > > > > > > > They don't use primary/secondary processes, though, > > > > > > > > > so the=C2=A0 > > > > > > > > > issue is=C2=A0=C2=A0never hit. I'm in a situation where u= sing > > > > > > > > > cgo=C2=A0 > > > > > > > > > seemed like the easiest=C2=A0=C2=A0path to accomplish wha= t I'm > > > > > > > > > doing=C2=A0 > > > > > > > > > since I needed specialized=C2=A0=C2=A0libraries for it th= at > > > > > > > > > were not=C2=A0 > > > > > > > > > available in C/C++. At some point I=C2=A0=C2=A0bet someon= e > > > > > > > > > would use=C2=A0 > > > > > > > > > Cython to start linking against DPDK as well,=C2=A0=C2=A0= and > > > > > > > > > we'd=C2=A0 > > > > > > > > > likely run into the same issue.> > > > For sure, we > > > > > > > > > want=C2=A0 > > > > > > > > > to support using DPDK with cgo or cython. > > > > > > > > > But it is not clear what is the relation with not > > > > > > > > > having=C2=A0 > > > > > > > > > the same compilation for primary and secondary. > > > > > > > > > Please=C2=A0 > > > > > > > > > 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-=C2=A0 > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=3Dm1R LQOGOk > > > > > > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-=C2=A0 > > > > > > > > 4&m=3DC69wDgrjDX8_oXp1M_3bnmWOOZd GqwBBG=C2=A0 > > > > > > > > 9vzkyGDWGQ&s=3DYYn2N7WrzJpH1ptNrLZad0nPAQdrUyqBckk2uFuWYP > > > > > > > > Q&e=3D > > > > > > > >=20 > > > > > > > > "The build system of the application does not have all > > > > > > > > the=C2=A0 > > > > > > > > subtelties of the DPDK build system, and ends up > > > > > > > > including > > > > > > > > *all* > > > > > > > > the constructors, wether they are used or not in the > > > > > > > > code.=C2=A0 > > > > > > > > Moreover, they are included in a different order. > > > > > > > > Actually,=C2=A0 > > > > > > > > by default the builds include no constructors at all > > > > > > > > (which=C2=A0 > > > > > > > > is a big fail), so the library needs to be included > > > > > > > > with=C2=A0 > > > > > > > > --whole-archive (see Snort DPDK instructions)." > > > > > > > >=20 > > > > > > > > I will get to the bottom of my exact case to > > > > > > > > understand=C2=A0 > > > > > > > > what's happening, but my primary application is a cgo=C2=A0 > > > > > > > > application that I'm linking to by using almost exactly > > > > > > > > the=C2=A0 > > > > > > > > same flags that are used in the DPDK build system to > > > > > > > > build=C2=A0 > > > > > > > > examples. The DPDK libraries I'm linking against is a > > > > > > > > single=C2=A0 > > > > > > > > location for both primary and secondary; in other > > > > > > > > words, I=C2=A0 > > > > > > > > don't build DPDK twice. > > > > > > > >=20 > > > > > > > > OK I understand, thanks. > > > > > > > >=20 > > > > > > > > You had alluded to a pkg-config for DPDK in the 2015 > > > > > > > > thread,=C2=A0 > > > > > > > > which cgo can use, but I don't know if that ever was=C2=A0 > > > > > > > > implemented. Cgo can use pkg-config if it's available,=C2= =A0 > > > > > > > > otherwise the only tools are specifying LDFLAGS and > > > > > > > > CFLAGS=C2=A0 > > > > > > > > into their build system. > > > > > > >=20 > > > > > > > Yes, the right answer is still pkg-config :) The good > > > > > > > news is=C2=A0 > > > > > > > that it is now implemented thanks to the meson build > > > > > > > system: > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__git.d > > > > > > > pdk. > > > > > > > org_dp > > > > > > > dk_tree_doc_build-2Dsdk-2Dmeson.txt- > > > > > > > 23n182&d=3DDwICAg&c=3Djcv3orpCsv7C4 > > > > > > > ly8- > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=3Dm1RLQOGOkz9MauvVLZmiGtyWc5mA > > > > > > > 7Dej > > > > > > > bP > > > > > > > FNE1IDj- > > > > > > > > 4&m=3DC69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDWGQ&s=3DoC86K > > > > > > > > D_R > > > > > > >=20 > > > > > > > J1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=3D > > > > > >=20 > > > > > > Hi Thomas, are there instructions on how to use pkg-config > > > > > > to=C2=A0 > > > > > > build the mlx4/5 PMD? I noticed a patch was submitted in=C2=A0 > > > > > > September to add support for it, but that link you provided > > > > > > on=C2=A0 > > > > > > using meson doesn't say how to build specific drivers. It=C2=A0 > > > > > > appears to be disabled by default. > > > > > > If the dependency is found, meson will enable the PMD when=C2= =A0 > > > > > > building DPDK. > > > > >=20 > > > > > Do you know where exactly that is? I've been using mlx5 for > > > > > a=C2=A0 > > > > > 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 > > > > normally=C2=A0 > > > > linked in. Instead, they should be loaded from the drivers > > > > directory=C2=A0 > > > > as .so files > > > > - normally by default in EAL as the driver .so's should be > > > > copied to=C2=A0 > > > > the EAL_PMD_PATH where EAL finds them automatically. [This > > > > applies=C2=A0 > > > > to both meson and make builds, though only meson generates the > > > > .pc=C2=A0 > > > > file for pkg-config] > > > >=20 > > > > If you are doing a static build, then you need to explicitly > > > > link in=C2=A0 > > > > the drivers. You can get a list from pkg-config using the " > > > > --static" flag in this case. A good example of how to use pkg-=C2= =A0 > > > > config in this way can be found in the Makefiles for most > > > > examples,=C2=A0 > > > > e.g. examples/helloworld/Makefile, reproduced below. > > > >=20 > > > > Regards, > > > > /Bruce > > > >=20 > > > > all: shared > > > > .PHONY: shared static > > > > shared: build/$(APP)-shared > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ln -sf $(APP)-share= d build/$(APP) > > > > static: build/$(APP)-static > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ln -sf $(APP)-stati= c build/$(APP) > > > >=20 > > > > PC_FILE :=3D $(shell pkg-config --path libdpdk) CFLAGS +=3D -O3 > > > > $(shell=C2=A0 > > > > pkg-config --cflags libdpdk) LDFLAGS_SHARED =3D $(shell pkg- > > > > config --=C2=A0 > > > > libs libdpdk) LDFLAGS_STATIC =3D -Wl,-Bstatic $(shell pkg-config > > > > --=C2=A0 > > > > static --libs libdpdk) > > > >=20 > > > > build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0$(CC) $(CFLAGS) $(S= RCS-y) -o $@ $(LDFLAGS) > > > > $(LDFLAGS_SHARED) > > > >=20 > > > > build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0$(CC) $(CFLAGS) $(S= RCS-y) -o $@ $(LDFLAGS) > > > > $(LDFLAGS_STATIC) > > > >=20 > > > > build: > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0@mkdir -p $@ > > >=20 > > > Thanks Bruce. I tried getting this to compile using cgo, and > > > it's=C2=A0 > > > causing more pain than it's worth. I used the --static --libs > > > options,=C2=A0 > > > and there were still numerous linker errors, some specific to > > > mlx, and=C2=A0 > > > some not. Specifically libmlx5 and libmnl are both needed, but > > > they're=C2=A0 > > > not part of the linker line from pkg-config. At this point I'll > > > just=C2=A0 > > > break the Go application up into a separate C application that > > > handles=C2=A0 > > > all the DPDK parts, and 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 > > entry, and pkg-config --libs --static libdpdk.pc does print them as > > intended. This is with 18.11-rc3. > > Are you sure everything is correct (pkg-config path is right, -- > > 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 > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev -lrte_power > -lrte_ip_frag -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 -lrte_cryptodev > -lrte_sched -lrte_latencystats -lrte_efd -lrte_distributor > -lrte_meter -lrte_acl -lrte_member -lrte_cmdline -lrte_lpm -lrte_kni > -lrte_cfgfile -lrte_bitratestats -lrte_timer -lrte_flow_classify > -lrte_mempool_bucket -lrte_pmd_null_crypto -lrte_pmd_failsafe > -lrte_bus_ifpga -lrte_pmd_atlantic -lrte_pmd_mlx4 -lrte_pmd_vmxnet3 > -lrte_pmd_avp -lrte_common_dpaax -lrte_pmd_ena -lcrypto > -lrte_bus_fslmc -ldl -lrte_pmd_avf -lrte_pmd_crypto_scheduler > -lrte_pmd_netvsc -lrte_pmd_vhost -lrte_bus_dpaa -lrte_mempool_dpaa2 > -lrte_common_octeontx -lrte_pmd_liquidio -lrte_pmd_ifc -Wl,-Bdynamic > -lnuma -lrte_pmd_enic -lrte_common_cpt -pthread > -lrte_pmd_octeontx_crypto -lrte_pmd_qat -lrte_bus_vmbus > -lrte_pmd_null -lm -lrte_pmd_dpaa -lrte_bus_vdev -lrte_pmd_dpaa2 > -lrte_pmd_skeleton_event -lrte_pmd_af_packet -lrte_pmd_octeontx > -lrte_pmd_thunderx -lrte_pmd_ring -lrte_pmd_octeontx_event > -lrte_pmd_sw_event -lrte_pmd_ark -lrte_mempool_octeontx > -lrte_pmd_ixgbe -lrte_pmd_kni -lrte_mempool_ring > -lrte_pmd_virtio_crypto -lrte_mempool_dpaa -lrte_pmd_dpaa2_cmdif > -lrte_bus_pci -lrte_pmd_opdl_event -lrte_pmd_mlx5 -lrte_pmd_virtio > -lrte_pmd_tap -lrte_pmd_caam_jr -lrte_pmd_dpaa2_sec > -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc -lrte_pmd_sfc -lrte_pmd_bnxt > -lrte_pmd_dpaa2_event -lrte_pmd_cxgbe -Wl,--whole-archive -Wl,--no- > as-needed -lrte_pmd_e1000 -lrte_pmd_softnic -lrte_pmd_bond > -lrte_pmd_fm10k -lrte_pmd_i40e -lrte_pmd_nfp -lrte_pmd_qede -Wl,--no- > whole-archive -lrte_pmd_axgbe -lrte_pmd_ccp -lrte_pmd_ifpga_rawdev > -lrte_pmd_bbdev_null -lrte_pmd_openssl -lrte_pmd_dsw_event > -lrte_pmd_dpaa_event -lrte_mempool_stack -lrte_pmd_vdev_netvsc > -lrte_pmd_dpaa_sec -lrte_pmd_skeleton_rawdev > -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 > put it in there for some reason? Were mlx5/mnl found at meson configure time? --=20 Kind regards, Luca Boccassi