From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id ED3877E99 for ; Tue, 21 Oct 2014 20:20:30 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 21 Oct 2014 11:23:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,762,1406617200"; d="scan'208";a="593090962" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by orsmga001.jf.intel.com with ESMTP; 21 Oct 2014 06:22:32 -0700 Received: from irsmsx153.ger.corp.intel.com (163.33.192.75) by IRSMSX103.ger.corp.intel.com (163.33.3.157) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 21 Oct 2014 14:22:27 +0100 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.21]) by IRSMSX153.ger.corp.intel.com ([169.254.9.23]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 14:22:27 +0100 From: "Gonzalez Monroy, Sergio" To: 'Matthew Hall' Thread-Topic: [dpdk-dev] virtio UIO / PMD issues in default Ubuntu Cloud Images Thread-Index: AQHP6ehxuLBN4M/t6UygCrZQnHQl2Jw5BMRg Date: Tue, 21 Oct 2014 13:22:27 +0000 Message-ID: <91383E96CE459D47BCE92EFBF5CE73B0C7F8B4@IRSMSX108.ger.corp.intel.com> References: <20141014054523.GA16919@mhcomputing.net> <20141014060353.GA17053@mhcomputing.net> <20141014063406.GA17242@mhcomputing.net> <91383E96CE459D47BCE92EFBF5CE73B0C7E467@IRSMSX108.ger.corp.intel.com> <3CCF4B14-58A7-4499-98A1-8D617A6F86B7@mhcomputing.net> <91383E96CE459D47BCE92EFBF5CE73B0C7E4E4@IRSMSX108.ger.corp.intel.com> <20141017085649.GA4210@mhcomputing.net> In-Reply-To: <20141017085649.GA4210@mhcomputing.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] virtio UIO / PMD issues in default Ubuntu Cloud Images X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 18:20:33 -0000 Hi Matthew, > -----Original Message----- > From: Matthew Hall [mailto:mhall@mhcomputing.net] > Sent: Friday, October 17, 2014 9:57 AM > To: Gonzalez Monroy, Sergio > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] virtio UIO / PMD issues in default Ubuntu Cloud > Images >=20 [...] > The virtio non UIO PMD doesn't depend on DPDK even if everything's built = as > a .so . To me this seems buggy but maybe I missed something: >=20 > $ ldd librte_pmd_virtio.so > linux-vdso.so.1 =3D> (0x00007fff7adfe000) > libc.so.6 =3D> /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa0d810c000) > /lib64/ld-linux-x86-64.so.2 (0x00007fa0d86ed000) >=20 You are right about the dependency (probably I did not explain the issue pr= operly). As you point out below, when building static DPDK we should not expect ldd = to report any DPDK dependency. When building shared DPDK libs, we should expect such dependency expect for= the fact that we are not linking against DPDK libraries when building librte_pmd_virtio.so, which as you mention is buggy= . The problem is not exclusive of librte_pmd_virtio.so module as you can easi= ly check by doing ldd on DPDK shared libraries. One way to fix the buggy behavior with librte_pmd_virtio would be to build = against dpdk libs when dpdk is built as shared libs. The issue is that we have two different ways of building DPDK, static or sh= ared libs, and the building process differs. Let's use librte_pmd_virtio shared object building process as an example: - we do not want to build against static DPDK libraries as this would resul= t in duplicated code in librte_pmd_virtio and other apps (ie. testpmd) - we want to link against shared DPDK libs to add dependencies and provide = reliable information (ie. ldd) Currently librte_pmd_virtio is built without linking against PDDK libs, the= refore no dependencies are included even when DPDK is built as shared libs. With this way of building the shared object, the module will be loaded succ= essfully on apps built with static/shared DPDK libs as long as all undefine= d symbols in librte_pmd_virtio are defined in either the app (for static) or = any of the loaded shared libs (for shared). > Now, about the problems... >=20 I have not been able to reproduce these problems. My setup was QEMU, dpdk-1.7.1, virtio-net-pmd, fedora 20 (both host and gue= st), GCC/CLANG. I have successfully loaded the module running testpmd with static/shared DP= DK libs using GCC and CLANG. [...] > 2) The second problem concerns compiling against DPDK 1.7.1 (plug my mino= r > clang compilation fixes) with these settings: >=20 > # Compile to share library > CONFIG_RTE_BUILD_SHARED_LIB=3Dn > # Combine to one single library > CONFIG_RTE_BUILD_COMBINE_LIBS=3Dy > CONFIG_RTE_LIBNAME=3D"intel_dpdk" >=20 > Then virtio-net-pmd is compiled using make > RTE_INCLUDE=3D../dpdk/build/include . > Just as printed above, no runtime dependency on DPDK is there (as > expected in the static case, but not what I believe should be expected in= the > dynamic case). >=20 > From there, the app is launched. Then the following error appears, and no > Ethernet ports can be detected since the builtin UIO PMD driver can't see= the > ports either, so the app exits. >=20 > EAL: open shared lib /vagrant/external/virtio-net-pmd/librte_pmd_virtio.s= o > EAL: /vagrant/external/virtio-net-pmd/librte_pmd_virtio.so: undefined > symbol: per_lcore__lcore_id >=20 Are we talking about a DPDK or custom app? Do you only see the issue when CONFIG_RTE_BUILD_COMBINE_LIBS=3Dy? > Running nm and nm -D shows this: >=20 > $ nm librte_pmd_virtio.so | fgrep -i per_lcore__lcore_id U > per_lcore__lcore_id >=20 This is expected behavior as the symbol is defined in librte_eal. The dynamic linker will resolve the undefined reference when loading the mo= dule in run-time. Thanks, Sergio