Re: [dpdk-dev] virtio UIO / PMD issues in default Ubuntu Cloud Images

[Matthew Hall <mhall@mhcomputing.net>]

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.