From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.46.186]) by dpdk.org (Postfix) with ESMTP id 896487E80 for ; Wed, 22 Oct 2014 09:10:31 +0200 (CEST) Received: by mail.mhcomputing.net (Postfix, from userid 1000) id D82E480C50B; Wed, 22 Oct 2014 00:17:53 -0700 (PDT) Date: Wed, 22 Oct 2014 00:17:53 -0700 From: Matthew Hall To: "Gonzalez Monroy, Sergio" Message-ID: <20141022071753.GB6051@mhcomputing.net> 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> <91383E96CE459D47BCE92EFBF5CE73B0C7F8B4@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91383E96CE459D47BCE92EFBF5CE73B0C7F8B4@IRSMSX108.ger.corp.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Wed, 22 Oct 2014 07:10:31 -0000 On Tue, Oct 21, 2014 at 01:22:27PM +0000, Gonzalez Monroy, Sergio wrote: > 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. Yes. I agree. Can we see about fixing this bug? > - we do not want to build against static DPDK libraries as this would result > 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) OK... but now it's impossible to use librte_pmd_virtio w/o mandatory share library performance loss. I strongly dislike being force to do this. > > Now, about the problems... > > 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 guest), GCC/CLANG. I > have successfully loaded the module running testpmd with static/shared DPDK > libs using GCC and CLANG. OK... let me try to clarify this point again. In this official DPDK support device document, http://www.dpdk.org/doc/nics , it says: Paravirtualization virtio-net or virtio-net + uio (QEMU, VirtualBox) As I've stated, when testing this on VirtualBox it does not work for me and gets into an infinite initialization loop which I documented in my last mail. But the same code works fine if it's using the VBox Intel 82545EM VNIC and appropriate driver. Also the VBox virtio-net device works completely fine using the kernel virtio-net driver. This making the virtio PMD's the most likely suspect, especially since the UIO based one can't init itself, and the non UIO one gets stuck in the loop. So my question is very simple. 1) Who tested this setup using *****VirtualBox NOT QEMU*****? QEMU doesn't help at all for my app because I'm trying to prepackage it as a Vagrant VM and Vagrant uses VirtualBox. It also doesn't help repro my bug because the virtio-net device is not 100% same between QEMU and VBOX so you can't compare 1-1. 2) Who made the instructions to configure this with VirtualBox? I could not find any such thing. 3) Who ever got this to work right in the first place? It's been multiple weeks of emailing and I still have no answer who placed this inaccurate text on the website. Nobody answered the last guy who asked it in 2013 either. So now it's IMPOSSIBLE for me to know if it worked and I configured it wrong or it never worked in the first place. > > EAL: open shared lib /vagrant/external/virtio-net-pmd/librte_pmd_virtio.so > > EAL: /vagrant/external/virtio-net-pmd/librte_pmd_virtio.so: undefined > > symbol: per_lcore__lcore_id > > > Are we talking about a DPDK or custom app? > Do you only see the issue when CONFIG_RTE_BUILD_COMBINE_LIBS=y? Issue happens in my DPDK based app. Can happen anytime you use static linked DPDK app w/ the librte_pmd_virtio. Because the link process of librte_pmd_virtio is broken. > > Running nm and nm -D shows this: > > > > $ nm librte_pmd_virtio.so | fgrep -i per_lcore__lcore_id U > > per_lcore__lcore_id > > > This is expected behavior as the symbol is defined in librte_eal. > The dynamic linker will resolve the undefined reference when loading the module in run-time. I am aware it's "expected behavior". But have the undefined symbol, and no dependency upon the DPDK .so and no link against the DPDK .a is NOT "expected behavior". It will break anytime you try to make a static app with this PMD available. Matthew.