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 A9FF92F42 for ; Tue, 13 Nov 2018 17:38:10 +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 wADGb7CW018102; Tue, 13 Nov 2018 16:38:09 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=paUXo1qoNR+CSYopyc+QEqZNR3vS72fu8TCohJonsxI=; b=WkgGZpLrISrsmlwbL1064u5TEAN73vhaBxHVD47ub/Q4W+rZV+Swet8Mq30PL0uVb6PJ UDBhjdC5P6EpxN4XvXq40ZGec95r+9AOkqu//RMlXPwII9RDswjhgLXC6RRxMjBS6Hda 1mBUekB5mwpT31Ylz0fi/MjzwFsezuc7x0U5+Gj4JGYOjRB3S1VJ+x6PY7qRLdRjJRLh n1Q9Qy9f+nOiI2TGSzMWqGg7MQFrPO9f46Xqx8QqUl+ktMzQpdNavdNMoqvX2DdPEc16 vCUiEFdD3A/1RLPelvo0JrHde15l8+r3LMROwDz+VGvoTkdt+4SAXjQdigMtnn7PDxrb pw== From: "Burdick, Cliff" To: Thomas Monjalon CC: "Burakov, Anatoly" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs Thread-Index: AdR632/vnvJ3U124TOeqdBTRFJxhhAAjX12AAACgVoAAAhyMkAALanuAAA4AxoA= Date: Tue, 13 Nov 2018 16:38:08 +0000 Message-ID: <03A7D9A58FAFB54FBB01FEE199D7308A0134B8F23C@wdc1exchmbxp02.hq.corp.viasat.com> References: <03A7D9A58FAFB54FBB01FEE199D7308A0134B8EE1F@wdc1exchmbxp02.hq.corp.viasat.com> <1fb8df6f-8056-5e79-1a77-e17b6383ca1c@intel.com> <03A7D9A58FAFB54FBB01FEE199D7308A0134B8F187@wdc1exchmbxp02.hq.corp.viasat.com> <7642123.6x7mORRspS@xps> In-Reply-To: <7642123.6x7mORRspS@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_10:, , 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-1807170000 definitions=main-1811130151 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 16:38:11 -0000 -----Original Message----- From: Thomas Monjalon [mailto:thomas@monjalon.net]=20 Sent: Tuesday, November 13, 2018 8:07 AM To: Burdick, Cliff Cc: Burakov, Anatoly; dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is= missing tailqs 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,=20 > > >> but didn't receive any responses. I hit the same issue recently=20 > > >> when trying to use cgo (Golang) as a primary process linked to=20 > > >> libdpdk.a against a C++ application linked against the same=20 > > >> library.> > > > > >=20 > > > The question is to know why you don't have the same constructors=20 > > > in primary and seconday? > >=20 > > I've hit similar things in the past. I believe it was caused by our bui= ld system stripping out unused libraries (such as rte_hash) from the binary= and thus not calling the constructor in the primary, but doing so in the s= econdary (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, n= ot in the tailqs code (unless we specifically support having different link= ed libraries to primary and secondary?). >=20 > Right, I think the original author of the patch stated the reasons in the= link I provided. The build system seems like the most appropriate place to= fix it, but the patch got me going quickly. I think the question is whethe= r you want DPDK to support these other ways of linking. I'm certainly not t= he first to use cgo, since there's a virtual switch project doing the same: >=20 > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_lagopu > s_vsw&d=3DDwICAg&c=3Djcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=3Dm1RL= QOG > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=3DhQqVCNwW7eoEzB_hLFK97i8idS8FIqX > oPeclwsIZq7Y&s=3DBMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno4-SojKM&e=3D >=20 > 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 easiest path to ac= complish what I'm doing since I needed specialized libraries for it that we= re 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 compilat= ion for primary and secondary. Please could you elaborate? Hi Thomas, I think Jean explained it well here: https://dev.dpdk.narkive.co= m/ZM3a7QD1/dpdk-dev-bug-static-constructors-considered-evil "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, b= ut my primary application is a cgo application that I'm linking to by using= almost exactly the same flags that are used in the DPDK build system to bu= ild examples. The DPDK libraries I'm linking against is a single location f= or both primary and secondary; in other words, I don't build DPDK twice.=20 You had alluded to a pkg-config for DPDK in the 2015 thread, which cgo 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 CFLA= GS into their build system.