From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id F057A1B1EB for ; Wed, 14 Nov 2018 19:15:16 +0100 (CET) Received: by mail-wr1-f68.google.com with SMTP id j26-v6so18367576wre.1 for ; Wed, 14 Nov 2018 10:15:16 -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=+rMleVwzV8oFkwTjHshw2DPBiNLkvTAGXN4uXJA7SwI=; b=qn1cw2KwUEb80+3MyhNxY1t5HIvVM01y6i7pDcGqdUaE2SIAJ8CJV9mjn2FG42ByJZ vTUG70Wv+65YYRI+L4lh4hXLDX4SjkVGkfhh1+qEdcMaioArg9aErac55Mfl199Nq7Pc UdxQ6rPAGhPk7S6s+EAN/i4GbLPAf03wJCWa3pmZN4bHO404WObke8djvM1MjnS+04uu rtsjyrs0kObG7HkYeqlvlb7SZ/qQvJEEdQJy0mKAzJE3iVfm20oxPrTa3jcRdjfL3NnM H3zh2/eYnhnP1wztAAGDBJeYJn64sTWqLsiAuWTDF6KdoyFE+KvhRr6KjC7/rZ0S+hXk E1wg== X-Gm-Message-State: AGRZ1gJJaHOjS/vdq+Ba4qLsYHdLgHUTkv/oH38uzmr887TFw5twIeAC 78MI2dZUQcXhCpnbGSunO5w= X-Google-Smtp-Source: AJdET5cJlTA3Od8YKldpUXn+rzwECicg3mG5fTnnaP71h+PAilHT68I6UZM3gOnJt6C45kVq9PVi7g== X-Received: by 2002:adf:ffc9:: with SMTP id x9-v6mr2821390wrs.73.1542219316056; Wed, 14 Nov 2018 10:15:16 -0800 (PST) Received: from localhost ([2a01:4b00:f419:6f00:8361:8946:ba2b:d556]) by smtp.gmail.com with ESMTPSA id a12sm8131026wro.18.2018.11.14.10.15.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 14 Nov 2018 10:15:13 -0800 (PST) Message-ID: <1542219312.11515.15.camel@debian.org> From: Luca Boccassi To: "Burdick, Cliff" , Bruce Richardson Cc: Thomas Monjalon , "Burakov, Anatoly" , "dev@dpdk.org" Date: Wed, 14 Nov 2018 18:15:12 +0000 In-Reply-To: <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> <03A7D9A58FAFB54FBB01FEE199D7308A0134B8FA28@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: Wed, 14 Nov 2018 18:15:17 -0000 On Wed, 2018-11-14 at 17:40 +0000, Burdick, Cliff wrote: >=20 > -----Original Message----- > From: Bruce Richardson [mailto:bruce.richardson@intel.com]=C2=A0 > 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 >=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.com > > > 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 > > > > > > > > > > the=C2=A0 > > > > > > > > > > same issue recently when trying to use cgo (Golang) > > > > > > > > > > as a=C2=A0 > > > > > > > > > > primary process linked to libdpdk.a against a C++=C2=A0 > > > > > > > > > > application linked against the same 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 > > > > > > > > caused=C2=A0 > > > > > > > > by our build system stripping out unused libraries > > > > > > > > (such as=C2=A0 > > > > > > > > rte_hash) from the binary and thus not calling the=C2=A0 > > > > > > > > constructor in the primary, but doing so in the > > > > > > > > secondary=C2=A0 > > > > > > > > (or something to that effect). In any case, this is > > > > > > > > caused=C2=A0 > > > > > > > > by linking different number of libraries to primary > > > > > > > > and=C2=A0 > > > > > > > > secondary, and should probably be fixed in the build > > > > > > > > system,=C2=A0 > > > > > > > > not in the tailqs code (unless we specifically support=C2= =A0 > > > > > > > > having different linked libraries to primary and=C2=A0 > > > > > > > > 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 > > > > > > > like=C2=A0 > > > > > > > the most appropriate place to fix it, but the patch got > > > > > > > me=C2=A0 > > > > > > > going quickly. I think the question is whether you want > > > > > > > DPDK=C2=A0 > > > > > > > to support these other ways of linking. I'm certainly not > > > > > > > the=C2=A0 > > > > > > > first to use cgo, since there's a 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=C2=A0 > > > > > > > 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 using= cgo > > > > > > > seemed=C2=A0 > > > > > > > like the easiest=C2=A0=C2=A0path to accomplish what I'm doing= since > > > > > > > I=C2=A0 > > > > > > > needed specialized=C2=A0=C2=A0libraries for it that were not > > > > > > > available in=C2=A0 > > > > > > > C/C++. At some point I=C2=A0=C2=A0bet someone would use Cytho= n to > > > > > > > start=C2=A0 > > > > > > > linking against DPDK as well,=C2=A0=C2=A0and we'd likely run = into > > > > > > > the=C2=A0 > > > > > > > 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=C2=A0 > > > > > > > same compilation for primary and secondary. Please could > > > > > > > you=C2=A0 > > > > > > > elaborate?> > > > > > > > >=20 > > > > > > Hi Thomas, I think Jean explained it well here: > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__dev.dp > > > > > > dk.narkive. > > > > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-2Dconstructors- > > > > > > 2Dconsider > > > > > > ed-2De=C2=A0 > > > > > > vil&d=3DDwICAg&c=3Djcv3orpCsv7C4ly8- > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=3Dm1R > > > > > > LQOGOk=C2=A0 > > > > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj- > > > > > > 4&m=3DC69wDgrjDX8_oXp1M_3bnmWOOZd > > > > > > GqwBBG=C2=A0 > > > > > > 9vzkyGDWGQ&s=3DYYn2N7WrzJpH1ptNrLZad0nPAQdrUyqBckk2uFuWYPQ&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*=C2=A0 > > > > > > the constructors, wether they are used or not in the code.=C2= =A0 > > > > > > Moreover, they are included in a different order. Actually, > > > > > > by=C2=A0 > > > > > > default the builds include no constructors at all (which is > > > > > > a=C2=A0 > > > > > > 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 > > > > > > what's=C2=A0 > > > > > > happening, but my primary application is a cgo application > > > > > > that=C2=A0 > > > > > > I'm linking to by using almost exactly the same flags that > > > > > > are=C2=A0 > > > > > > used in the DPDK build system to build examples. The DPDK=C2=A0 > > > > > > libraries I'm linking against is a single location for > > > > > > both=C2=A0 > > > > > > primary and secondary; in 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 > > > > > > 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, > > > > > > otherwise=C2=A0 > > > > > > the only tools are specifying LDFLAGS and CFLAGS into their > > > > > > build system. > > > > >=20 > > > > > Yes, the right answer is still pkg-config :) The good news is > > > > > 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.dpdk. > > > > > org_dp > > > > > dk_tree_doc_build-2Dsdk-2Dmeson.txt- > > > > > 23n182&d=3DDwICAg&c=3Djcv3orpCsv7C4 > > > > > ly8- > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=3Dm1RLQOGOkz9MauvVLZmiGtyWc5mA7Dej > > > > > bP > > > > > FNE1IDj- > > > > > >4&m=3DC69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDWGQ&s=3DoC86KD_R > > > > > J1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=3D > > > >=20 > > > > 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. > > >=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 was missing? > > >=20 > >=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 meson 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 this case. A good example of how to use pkg- > > config in this way can be found in the Makefiles for most examples, > > 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)-shared bu= ild/$(APP) > > static: build/$(APP)-static > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ln -sf $(APP)-static bu= ild/$(APP) > >=20 > > PC_FILE :=3D $(shell pkg-config --path libdpdk) CFLAGS +=3D -O3 $(shell > > pkg-config --cflags libdpdk) LDFLAGS_SHARED =3D $(shell pkg-config -- > > libs libdpdk) LDFLAGS_STATIC =3D -Wl,-Bstatic $(shell pkg-config -- > > 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) $(SRCS-= 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) $(SRCS-= 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 > causing more pain than it's worth. I used the --static --libs > options, and there were still numerous linker errors, some specific > to mlx, and some not. Specifically libmlx5 and libmnl are both > needed, but they're not part of the linker 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 messages > between them. Hi, 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