[dpdk-users] Difficulty With rte_eal_init()

[dpdk-users] Difficulty With rte_eal_init()

[Cliff Burdick]

Hi, I've been trying to create a standalone application linked against
DPDK, and I'm having some issues getting the program to run properly. The
main problem is that in my standalone app compared to the example code,
rte_eal_init() from the example code seems to probe the PCI bus, whereas
mine doesn't. Here is a snippet from mine and an example:

mine:
EAL: Virtual area found at 0x7f93ad000000 (size = 0x200000)
EAL: Ask a virtual area of 0x3fc00000 bytes
EAL: Virtual area found at 0x7f936d200000 (size = 0x3fc00000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7f936ce00000 (size = 0x200000)
EAL: Requesting 512 pages of size 2MB from socket 0
EAL: Requesting 512 pages of size 2MB from socket 1
EAL: TSC frequency is ~2500000 KHz
EAL: Master lcore 0 is ready (tid=ef4e6940;cpuset=[0])
EAL: lcore 6 is ready (tid=699ed700;cpuset=[6])
EAL: lcore 7 is ready (tid=691ec700;cpuset=[7])
EAL: lcore 4 is ready (tid=6a9ef700;cpuset=[4])
EAL: lcore 1 is ready (tid=6c1f2700;cpuset=[1])
EAL: lcore 2 is ready (tid=6b9f1700;cpuset=[2])
EAL: lcore 3 is ready (tid=6b1f0700;cpuset=[3])
EAL: lcore 5 is ready (tid=6a1ee700;cpuset=[5])

example:
EAL: Requesting 512 pages of size 2MB from socket 1
EAL: TSC frequency is ~2500000 KHz
EAL: Master lcore 0 is ready (tid=3019a900;cpuset=[0])
EAL: lcore 6 is ready (tid=aabed700;cpuset=[6])
EAL: lcore 5 is ready (tid=ab3ee700;cpuset=[5])
EAL: lcore 7 is ready (tid=aa3ec700;cpuset=[7])
EAL: lcore 1 is ready (tid=ad3f2700;cpuset=[1])
EAL: lcore 3 is ready (tid=ac3f0700;cpuset=[3])
EAL: lcore 2 is ready (tid=acbf1700;cpuset=[2])
EAL: lcore 4 is ready (tid=abbef700;cpuset=[4])
EAL: PCI device 0000:04:00.0 on NUMA socket 0
EAL:   probe driver: 8086:1572 rte_i40e_pmd
EAL:   Not managed by a supported kernel driver, skipped
EAL: PCI device 0000:04:00.1 on NUMA socket 0
EAL:   probe driver: 8086:1572 rte_i40e_pmd
EAL:   Not managed by a supported kernel driver, skipped
EAL: PCI device 0000:04:00.2 on NUMA socket 0
...

I even went so far as to port the dpdk part of my C++ code to C, then
compile it into a standalone executable with the Makefile copied from an
example. Sure enough, this worked and the PCI bus was scanned. However,
when I then tried compiling the dpdk part of my app into a library and
linking against it from my main program, the PCI scanning goes away and no
devices are found. I can't really use the DPDK makefiles easily for my
entire program since I'm using automake. Has anyone had this issue?

Re: [dpdk-users] Difficulty With rte_eal_init()

[Matthew Hall]

On Fri, Mar 18, 2016 at 02:45:10PM -0700, Cliff Burdick wrote:
> Hi, I've been trying to create a standalone application linked against
> DPDK, and I'm having some issues getting the program to run properly. The
> main problem is that in my standalone app compared to the example code,
> rte_eal_init() from the example code seems to probe the PCI bus, whereas
> mine doesn't.
[SNIP]
> However, when I then tried compiling the dpdk part of my app into a library 
> and linking against it from my main program, the PCI scanning goes away and 
> no devices are found.

This hoses up every new app developer. Especially me, as I used DPDK before 
the PCI probe behavior was changed between versions and got totally lost when 
it broke. You need the following:

Build Configuration:

CONFIG_RTE_BUILD_COMBINE_LIBS=y

Linker Flags (LDFLAGS):

-Wl,--whole-archive -Wl,--start-group -ldpdk -Wl,--end-group -Wl,--no-whole-archive

Sincerely.
Matthew.

Re: [dpdk-users] Difficulty With rte_eal_init()

[Cliff Burdick]

In regards to your fix above, how does this change the probing behavior? It
seems that it's just combining all the .a files into a single library,
right? I still needed to include that whole lost if -D options that the
examples use, or it still didn't seem to probe the bus. I must be missing
something else as well. Do you mind pasting all of the defines/libraries
that you pass into your app to get it to work? Currently the examples in
mine pass this large list:

-march=native -DRTE_MACHINE_CPUFLAG_SSE -DRTE_MACHINE_CPUFLAG_SSE2
-DRTE_MACHINE_CPUFLAG_SSE3 -DRTE_MACHINE_CPUFLAG_SSSE3
-DRTE_MACHINE_CPUFLAG_SSE4_1 -DRTE_MACHINE_CPUFLAG_SSE4_2
-DRTE_MACHINE_CPUFLAG_PCLMULQDQ -DRTE_MACHINE_CPUFLAG_AVX
-DRTE_MACHINE_CPUFLAG_RDRAND -DRTE_MACHINE_CPUFLAG_FSGSBASE
-DRTE_MACHINE_CPUFLAG_F16C -DRTE_MACHINE_CPUFLAG_AVX2
-DRTE_COMPILE_TIME_CPUFLAGS=RTE_CPUFLAG_SSE,RTE_CPUFLAG_SSE2,RTE_CPUFLAG_SSE3,RTE_CPUFLAG_SSSE3,RTE_CPUFLAG_SSE4_1,RTE_CPUFLAG_SSE4_2,RTE_CPUFLAG_PCLMULQDQ,RTE_CPUFLAG_AVX,RTE_CPUFLAG_RDRAND,RTE_CPUFLAG_FSGSBASE,RTE_CPUFLAG_F16C,RTE_CPUFLAG_AVX2
  -include $(RTE_SDK)/include/rte_config.h -O3


On Fri, Mar 18, 2016 at 2:56 PM, Matthew Hall <mhall@mhcomputing.net> wrote:

> On Fri, Mar 18, 2016 at 02:45:10PM -0700, Cliff Burdick wrote:
> > Hi, I've been trying to create a standalone application linked against
> > DPDK, and I'm having some issues getting the program to run properly. The
> > main problem is that in my standalone app compared to the example code,
> > rte_eal_init() from the example code seems to probe the PCI bus, whereas
> > mine doesn't.
> [SNIP]
> > However, when I then tried compiling the dpdk part of my app into a
> library
> > and linking against it from my main program, the PCI scanning goes away
> and
> > no devices are found.
>
> This hoses up every new app developer. Especially me, as I used DPDK before
> the PCI probe behavior was changed between versions and got totally lost
> when
> it broke. You need the following:
>
> Build Configuration:
>
> CONFIG_RTE_BUILD_COMBINE_LIBS=y
>
> Linker Flags (LDFLAGS):
>
> -Wl,--whole-archive -Wl,--start-group -ldpdk -Wl,--end-group
> -Wl,--no-whole-archive
>
> Sincerely.
> Matthew.
>

Re: [dpdk-users] Difficulty With rte_eal_init()

[Matthew Hall]

On Fri, Mar 18, 2016 at 04:40:28PM -0700, Cliff Burdick wrote:
> In regards to your fix above, how does this change the probing behavior? It
> seems that it's just combining all the .a files into a single library,
> right?

Without these link flags, the constructor functions, which cause ethdev 
drivers to register themselves as probe-able via PCI, do not get invoked 
during library load-time, and the probing always screws up, finding zero 
working Ethernet ports.

> I still needed to include that whole lost if -D options that the
> examples use, or it still didn't seem to probe the bus. I must be missing
> something else as well.

If you have to pass all these -DRTE_MACHINE_* it is most frequently caused by 
an outdated C / C++ compiler. The most recent report of it, which I witnessed, 
then saw reported by a second party on the DPDK mailing list, was caused by a 
branch of clang which was too old to enable the correct accelerations for 
the Haswell, Broadwell, and Skylake series.

The other thing could be you didn't pull in the rte_config.h using -include 
$(RTE_INCLUDE)/rte_config.h and -isystem$(RTE_INCLUDE).

Matthew.

Re: [dpdk-users] Difficulty With rte_eal_init()

[gowrishankar]

Trying CONFIG_RTE_BUILD_SHARED_LIB=y and calling eal_plugin_add() for 
your dpdk driver .so
could solve this ?.

Regards,
Gowrishankar

On Saturday 19 March 2016 03:15 AM, Cliff Burdick wrote:
> Hi, I've been trying to create a standalone application linked against
> DPDK, and I'm having some issues getting the program to run properly. The
> main problem is that in my standalone app compared to the example code,
> rte_eal_init() from the example code seems to probe the PCI bus, whereas
> mine doesn't. Here is a snippet from mine and an example:
>
> mine:
> EAL: Virtual area found at 0x7f93ad000000 (size = 0x200000)
> EAL: Ask a virtual area of 0x3fc00000 bytes
> EAL: Virtual area found at 0x7f936d200000 (size = 0x3fc00000)
> EAL: Ask a virtual area of 0x200000 bytes
> EAL: Virtual area found at 0x7f936ce00000 (size = 0x200000)
> EAL: Requesting 512 pages of size 2MB from socket 0
> EAL: Requesting 512 pages of size 2MB from socket 1
> EAL: TSC frequency is ~2500000 KHz
> EAL: Master lcore 0 is ready (tid=ef4e6940;cpuset=[0])
> EAL: lcore 6 is ready (tid=699ed700;cpuset=[6])
> EAL: lcore 7 is ready (tid=691ec700;cpuset=[7])
> EAL: lcore 4 is ready (tid=6a9ef700;cpuset=[4])
> EAL: lcore 1 is ready (tid=6c1f2700;cpuset=[1])
> EAL: lcore 2 is ready (tid=6b9f1700;cpuset=[2])
> EAL: lcore 3 is ready (tid=6b1f0700;cpuset=[3])
> EAL: lcore 5 is ready (tid=6a1ee700;cpuset=[5])
>
> example:
> EAL: Requesting 512 pages of size 2MB from socket 1
> EAL: TSC frequency is ~2500000 KHz
> EAL: Master lcore 0 is ready (tid=3019a900;cpuset=[0])
> EAL: lcore 6 is ready (tid=aabed700;cpuset=[6])
> EAL: lcore 5 is ready (tid=ab3ee700;cpuset=[5])
> EAL: lcore 7 is ready (tid=aa3ec700;cpuset=[7])
> EAL: lcore 1 is ready (tid=ad3f2700;cpuset=[1])
> EAL: lcore 3 is ready (tid=ac3f0700;cpuset=[3])
> EAL: lcore 2 is ready (tid=acbf1700;cpuset=[2])
> EAL: lcore 4 is ready (tid=abbef700;cpuset=[4])
> EAL: PCI device 0000:04:00.0 on NUMA socket 0
> EAL:   probe driver: 8086:1572 rte_i40e_pmd
> EAL:   Not managed by a supported kernel driver, skipped
> EAL: PCI device 0000:04:00.1 on NUMA socket 0
> EAL:   probe driver: 8086:1572 rte_i40e_pmd
> EAL:   Not managed by a supported kernel driver, skipped
> EAL: PCI device 0000:04:00.2 on NUMA socket 0
> ...
>
> I even went so far as to port the dpdk part of my C++ code to C, then
> compile it into a standalone executable with the Makefile copied from an
> example. Sure enough, this worked and the PCI bus was scanned. However,
> when I then tried compiling the dpdk part of my app into a library and
> linking against it from my main program, the PCI scanning goes away and no
> devices are found. I can't really use the DPDK makefiles easily for my
> entire program since I'm using automake. Has anyone had this issue?
>

Re: [dpdk-users] Difficulty With rte_eal_init()

[Cliff Burdick]

Hi Matthew, sorry for the late response. I'm getting compilation errors
when I try to do what you suggested. I should have the same headers
included by the l2fwd example. I'm running g++ 4.8.5. Here are the new
errors and the compilation line:

g++  -I../inc -include
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_config.h
-isystem../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include
 -std=c++11 -g -O2 -MT app-Main.o -MD -MP -MF .deps/app-Main.Tpo -c -o
app-Main.o `test -f `Main.cpp' || echo './'`Main.cpp

../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h: In
function ‘void* rte_memcpy(void*, const void*, size_t)’:
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
../../dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_memcpy.h:625:2:
error: ‘_mm_alignr_epi8’ was not declared in this scope
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);



On Sat, Mar 19, 2016 at 11:16 PM, gowrishankar <
gowrishankar.m@linux.vnet.ibm.com> wrote:

> Trying CONFIG_RTE_BUILD_SHARED_LIB=y and calling eal_plugin_add() for your
> dpdk driver .so
> could solve this ?.
>
> Regards,
> Gowrishankar
>
>
> On Saturday 19 March 2016 03:15 AM, Cliff Burdick wrote:
>
>> Hi, I've been trying to create a standalone application linked against
>> DPDK, and I'm having some issues getting the program to run properly. The
>> main problem is that in my standalone app compared to the example code,
>> rte_eal_init() from the example code seems to probe the PCI bus, whereas
>> mine doesn't. Here is a snippet from mine and an example:
>>
>> mine:
>> EAL: Virtual area found at 0x7f93ad000000 (size = 0x200000)
>> EAL: Ask a virtual area of 0x3fc00000 bytes
>> EAL: Virtual area found at 0x7f936d200000 (size = 0x3fc00000)
>> EAL: Ask a virtual area of 0x200000 bytes
>> EAL: Virtual area found at 0x7f936ce00000 (size = 0x200000)
>> EAL: Requesting 512 pages of size 2MB from socket 0
>> EAL: Requesting 512 pages of size 2MB from socket 1
>> EAL: TSC frequency is ~2500000 KHz
>> EAL: Master lcore 0 is ready (tid=ef4e6940;cpuset=[0])
>> EAL: lcore 6 is ready (tid=699ed700;cpuset=[6])
>> EAL: lcore 7 is ready (tid=691ec700;cpuset=[7])
>> EAL: lcore 4 is ready (tid=6a9ef700;cpuset=[4])
>> EAL: lcore 1 is ready (tid=6c1f2700;cpuset=[1])
>> EAL: lcore 2 is ready (tid=6b9f1700;cpuset=[2])
>> EAL: lcore 3 is ready (tid=6b1f0700;cpuset=[3])
>> EAL: lcore 5 is ready (tid=6a1ee700;cpuset=[5])
>>
>> example:
>> EAL: Requesting 512 pages of size 2MB from socket 1
>> EAL: TSC frequency is ~2500000 KHz
>> EAL: Master lcore 0 is ready (tid=3019a900;cpuset=[0])
>> EAL: lcore 6 is ready (tid=aabed700;cpuset=[6])
>> EAL: lcore 5 is ready (tid=ab3ee700;cpuset=[5])
>> EAL: lcore 7 is ready (tid=aa3ec700;cpuset=[7])
>> EAL: lcore 1 is ready (tid=ad3f2700;cpuset=[1])
>> EAL: lcore 3 is ready (tid=ac3f0700;cpuset=[3])
>> EAL: lcore 2 is ready (tid=acbf1700;cpuset=[2])
>> EAL: lcore 4 is ready (tid=abbef700;cpuset=[4])
>> EAL: PCI device 0000:04:00.0 on NUMA socket 0
>> EAL:   probe driver: 8086:1572 rte_i40e_pmd
>> EAL:   Not managed by a supported kernel driver, skipped
>> EAL: PCI device 0000:04:00.1 on NUMA socket 0
>> EAL:   probe driver: 8086:1572 rte_i40e_pmd
>> EAL:   Not managed by a supported kernel driver, skipped
>> EAL: PCI device 0000:04:00.2 on NUMA socket 0
>> ...
>>
>> I even went so far as to port the dpdk part of my C++ code to C, then
>> compile it into a standalone executable with the Makefile copied from an
>> example. Sure enough, this worked and the PCI bus was scanned. However,
>> when I then tried compiling the dpdk part of my app into a library and
>> linking against it from my main program, the PCI scanning goes away and no
>> devices are found. I can't really use the DPDK makefiles easily for my
>> entire program since I'm using automake. Has anyone had this issue?
>>
>>
>
>

Re: [dpdk-users] Difficulty With rte_eal_init()

[Matthew Hall]

On Tue, Mar 29, 2016 at 02:16:45PM -0700, Cliff Burdick wrote:
> Hi Matthew, sorry for the late response. I'm getting compilation errors
> when I try to do what you suggested. I should have the same headers
> included by the l2fwd example. I'm running g++ 4.8.5. Here are the new
> errors and the compilation line:

All of those seemed to be referencing _mm_alignr_epi8 which is part of 
Supplemental Streaming SIMD Extensions 3 (SSSE3).

So you have to check GCC man page, docs, and code, to make sure whatever flag 
required for enabling Supplemental Streaming SIMD Extensions 3 (SSSE3) 
instructions is present or the intrinsic function implementations (which get 
stubbed out to the assembly trampoline for the instruction named) will not 
exist.

Personally, the fact that the intrinsics don't come with a default software 
implementation that raises a compile warning is one of my top hatreds 
associated with the use of these instructions. I've spent hours on issues like 
this w/ my DPDK app...

Matthew.

Re: [dpdk-users] Difficulty With rte_eal_init()

[Van Haaren, Harry]

> From: users [mailto:users-bounces@dpdk.org] On Behalf Of Matthew Hall
> Sent: Tuesday, March 29, 2016 10:31 PM
> To: Cliff Burdick <shaklee3@gmail.com>
> Cc: gowrishankar <gowrishankar.m@linux.vnet.ibm.com>; users@dpdk.org
> Subject: Re: [dpdk-users] Difficulty With rte_eal_init()
> 
> On Tue, Mar 29, 2016 at 02:16:45PM -0700, Cliff Burdick wrote:
> > Hi Matthew, sorry for the late response. I'm getting compilation errors
> > when I try to do what you suggested. I should have the same headers
> > included by the l2fwd example. I'm running g++ 4.8.5. Here are the new
> > errors and the compilation line:
> 
> All of those seemed to be referencing _mm_alignr_epi8 which is part of
> Supplemental Streaming SIMD Extensions 3 (SSSE3).

A very similar issue was discussed on list before:
http://thread.gmane.org/gmane.comp.networking.dpdk.devel/33144

With specific versions of clang this issue would show, while with a
newer one it would not. Given GCC is in question here, I'm not sure
exactly what the cause may be.

-Harry

Re: [dpdk-users] Difficulty With rte_eal_init()

[Cliff Burdick]

Thanks, -march=native fixed that. Now I get a segfault when calling
rte_eth_tx_queue_setup:

PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7fff755efa40
hw_ring=0x7fff755efe80 dma_addr=0x2005befe80
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6798aad in malloc_consolidate () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-106.el7_2.4.x86_64 libconfig-1.4.9-5.el7.x86_64
libgcc-4.8.5-4.el7.x86_64 libstdc++-4.8.5-4.el7.x86_64
(gdb) backtrace
#0  0x00007ffff6798aad in malloc_consolidate () from /lib64/libc.so.6
#1  0x00007ffff679aea5 in _int_malloc () from /lib64/libc.so.6
#2  0x00007ffff679d334 in calloc () from /lib64/libc.so.6
#3  0x00007ffff6790ed3 in open_memstream () from /lib64/libc.so.6
#4  0x00007ffff680d23a in __vsyslog_chk () from /lib64/libc.so.6
#5  0x00007ffff680d79f in syslog () from /lib64/libc.so.6
#6  0x00007ffff7970922 in console_log_write () from
dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/lib/libdpdk.so
#7  0x00007ffff6788a51 in _IO_cookie_write () from /lib64/libc.so.6
#8  0x00007ffff67947ec in __GI__IO_do_write () from /lib64/libc.so.6
#9  0x00007ffff6792be0 in __GI__IO_file_sync () from /lib64/libc.so.6
#10 0x00007ffff6788482 in fflush () from /lib64/libc.so.6
#11 0x00007ffff7a2462e in rte_vlog () from
dpdk-2.2.0/x86_64-native-linuxapp-gcc/lib/libdpdk.so
#12 0x00007ffff795150b in rte_log () from
dpdk-2.2.0/x86_64-native-linuxapp-gcc/lib/libdpdk.so
#13 0x00007ffff794df5f in ixgbe_dev_tx_queue_setup () from
dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/lib/libdpdk.so
#14 0x00007ffff7a7ab79 in rte_eth_tx_queue_setup () from
dpdk/dpdk-2.2.0/x86_64-native-linuxapp-gcc/lib/libdpdk.so
#15 0x0000000000404728 in app::DpdkMgr::ConfigurePorts
(this=this@entry=0x7fffffffe378,
macAddr="90:E2:BA:AF:A0:B8", numQ=numQ@entry=2) at DpdkMgr.cpp:114
#16 0x000000000040299d in app::appConfigure::ConfigureDpdkPorts
(this=this@entry=0x7fffffffe360) at appConfigure.cpp:155
#17 0x00000000004020af in main (argc=2, argv=<optimized out>) at
appMain.cpp:40

I've tried passing in identical parameters to what l2fwd does, but it just
doesn't seem to be working. I think I may end up just taking an identical
makefile from the examples directory and using it since I'm not getting
anywhere with this. I'm using automake, so it's a little cumbersome.





On Tue, Mar 29, 2016 at 2:30 PM, Matthew Hall <mhall@mhcomputing.net> wrote:

> On Tue, Mar 29, 2016 at 02:16:45PM -0700, Cliff Burdick wrote:
> > Hi Matthew, sorry for the late response. I'm getting compilation errors
> > when I try to do what you suggested. I should have the same headers
> > included by the l2fwd example. I'm running g++ 4.8.5. Here are the new
> > errors and the compilation line:
>
> All of those seemed to be referencing _mm_alignr_epi8 which is part of
> Supplemental Streaming SIMD Extensions 3 (SSSE3).
>
> So you have to check GCC man page, docs, and code, to make sure whatever
> flag
> required for enabling Supplemental Streaming SIMD Extensions 3 (SSSE3)
> instructions is present or the intrinsic function implementations (which
> get
> stubbed out to the assembly trampoline for the instruction named) will not
> exist.
>
> Personally, the fact that the intrinsics don't come with a default software
> implementation that raises a compile warning is one of my top hatreds
> associated with the use of these instructions. I've spent hours on issues
> like
> this w/ my DPDK app...
>
> Matthew.
>

Re: [dpdk-users] Difficulty With rte_eal_init()

[Matthew Hall]

On Wed, Mar 30, 2016 at 07:16:28AM -0700, Cliff Burdick wrote:
> Thanks, -march=native fixed that. Now I get a segfault when calling
> rte_eth_tx_queue_setup:
> 
> PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7fff755efa40
> hw_ring=0x7fff755efe80 dma_addr=0x2005befe80
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff6798aad in malloc_consolidate () from /lib64/libc.so.6
> Missing separate debuginfos, use: debuginfo-install
> glibc-2.17-106.el7_2.4.x86_64 libconfig-1.4.9-5.el7.x86_64
> libgcc-4.8.5-4.el7.x86_64 libstdc++-4.8.5-4.el7.x86_64

Rebuild your DPDK w/ "-g -O0" in the EXTRA_CFLAGS env var. Install the 
libc6-dbg symbols or equivalent. The BT is useless w/ no symbols.

Matthew.