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

["Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com>]

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
> 
[...]
> 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:
> 
> $ ldd librte_pmd_virtio.so
>     linux-vdso.so.1 =>  (0x00007fff7adfe000)
>     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa0d810c000)
>     /lib64/ld-linux-x86-64.so.2 (0x00007fa0d86ed000)
> 
You are right about the dependency (probably I did not explain the issue properly).

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 easily 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 shared 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 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)

Currently librte_pmd_virtio is built without linking against PDDK libs, therefore 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 successfully on apps built with static/shared DPDK libs as long as all undefined
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...
> 
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.

[...]
> 2) The second problem concerns compiling against DPDK 1.7.1 (plug my minor
> clang compilation fixes) with these settings:
> 
> # Compile to share library
> CONFIG_RTE_BUILD_SHARED_LIB=n
> # Combine to one single library
> CONFIG_RTE_BUILD_COMBINE_LIBS=y
> CONFIG_RTE_LIBNAME="intel_dpdk"
> 
> Then virtio-net-pmd is compiled using make
> RTE_INCLUDE=../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).
> 
> 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.
> 
> 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?

> 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.

Thanks,
Sergio