> -----Original Message----- > From: Matthew Hall [mailto:mhall at mhcomputing.net] > Subject: Re: [dpdk-dev] virtio UIO / PMD issues in default Ubuntu Cloud > Images > > > - 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. > You are not forced to use shared libraries. This module loads successfully with an app (testpmd) built against static DPDK libs.
> 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. > I have reproduced this issue in VirtualBox: - For UIO Virtio PMD, there is an issue with igb_uio module and virtio vbox backend device, I fail to bind igb_uio driver to the virtio device. - For non-UIO Virtio PMD, the module fails to initialize properly as you have indicated in your previous post (stuck in a loop). I get this behavior with testpmd regardless of DPDK being built as static or shared. > > > 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. > The linking is not broken if we are assuming apps built against static DPDK libs. I can't think of other way of linking this module to be used in apps with static DPDK libs. > > > 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. > Have you built static DPDK libs and run testpmd? Your undefined symbol error is most likely because the symbol is not in the dynamic symbol table of you app. You need to pass -rdynamic to GCC or -export-dynamic to LD when building your app. Thanks, Sergio > Matthew.
