From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mta-us-central-02.viasat.com (mta-us-central-02.viasat.com [8.37.103.59]) by dpdk.org (Postfix) with ESMTP id 896DD4CE4 for ; Wed, 14 Nov 2018 00:42:55 +0100 (CET) Received: from pps.filterd (wdc1mta01.viasat.com [127.0.0.1]) by wdc1mta01.viasat.com (8.16.0.22/8.16.0.22) with SMTP id wADNfn5J016885; Tue, 13 Nov 2018 23:42:53 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=SA3UeeruUD/BsOknSfAEnz0hr6tA/WWSyOJpPV+x3mA=; b=mvZo4LIh6Kv3ir4zpbGh409XaMdV4VCXRiA3CgWWBQySyfiwhOi0Jg4n7BduO5BsCrbe CAm5W2KHEDJs3nmjOrrxl46qW8sQPjdKjHL7zznZ7f+fWYuN3crFKp0oOLdyMGg2R/Xn 9CG7meL13nKU6o/F2B16z5Xy2/1iI1S1O+GGTxAfPYZPx34y3K+nW4EyaaW4L4N6ABre gk0I1T2ZrlYTa0fde2pYw5/KkxcwOjZjIrrt6aqOeK0lOjaMS7htE5H5fOt1DN8KUbyL PTVSo43A+9t5sJI3dXbQOBZaEPQNayyW5kacN1+eiMjTyR3YJMDdWaWjwBluKa+SMv5I 6w== From: "Burdick, Cliff" To: Thomas Monjalon CC: "Burakov, Anatoly" , "dev@dpdk.org" , "bruce.richardson@intel.com" Thread-Topic: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs Thread-Index: AdR632/vnvJ3U124TOeqdBTRFJxhhAAjX12AAACgVoAAAhyMkAALanuAAA4AxoD//5prAIAAGvTAgABCZID//6GNjw== Date: Tue, 13 Nov 2018 23:42:51 +0000 Message-ID: <03A7D9A58FAFB54FBB01FEE199D7308A0134B8F564@wdc1exchmbxp02.hq.corp.viasat.com> References: <03A7D9A58FAFB54FBB01FEE199D7308A0134B8EE1F@wdc1exchmbxp02.hq.corp.viasat.com> <2172258.pSIRIAPMh3@xps> <03A7D9A58FAFB54FBB01FEE199D7308A0134B8F4C4@wdc1exchmbxp02.hq.corp.viasat.com>, <1843907.qCN5czUxPS@xps> In-Reply-To: <1843907.qCN5czUxPS@xps> 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-13_17:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 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-1811130211 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 23:42:55 -0000 ________________________________________ 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 primary is= missing tailqs 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 recentl= y > > > > > >> 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 constructor= s > > > > > > in primary and seconday? > > > > > > > > > > I've hit similar things in the past. I believe it was caused by o= ur > > > > > build system stripping out unused libraries (such as rte_hash) fr= om > > > > > the binary and thus not calling the constructor in the primary, b= ut > > > > > 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 appropria= te > > > > 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=3Dhttps-3A__github.com_l= ago > > > > pu > > > > s_vsw&d=3DDwICAg&c=3Djcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r= =3Dm1RLQ > > > > OG > > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=3DhQqVCNwW7eoEzB_hLFK97i8idS= 8FI > > > > qX oPeclwsIZq7Y&s=3DBMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno4-SojKM&e= =3D > > > > > > > > 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 easie= st > > > > 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=3Dhttps-3A__dev.dpdk.narki= ve. > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-2Dconstructors-2Dconsidered-2D= e > > > vil&d=3DDwICAg&c=3Djcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=3Dm1= RLQOGOk > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=3DC69wDgrjDX8_oXp1M_3bnmWOOZdGqw= BBG > > > 9vzkyGDWGQ&s=3DYYn2N7WrzJpH1ptNrLZad0nPAQdrUyqBckk2uFuWYPQ&e=3D > > > > > > "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 th= e > > > 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 cg= o > > > 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=3Dhttp-3A__git.dpdk.org_= dpdk_tree_doc_build-2Dsdk-2Dmeson.txt-23n182&d=3DDwICAg&c=3Djcv3orpCsv7C4ly= 8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=3Dm1RLQOGOkz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-= >4&m=3DC69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDWGQ&s=3DoC86KD_RJ1T6rfzi3x5z= FT1Ri13ELpKmsyFqpgDbgFg&e=3D > > Hi Thomas, are there instructions on how to use pkg-config to build the m= lx4/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 spec= ific drivers. It appears to be disabled by default. > If the dependency is found, meson will enable the PMD when building DPDK. 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 m= issing?