Suricata compilation problem with DPDK on ARM platform

Help
1

Hello
I am doing experiments with Suricata and ARM using this board: HoneyComb LX2 - Arm Workstation & Developer Platform | SolidRun.
I am trying to compile Suricata with DPDK and NXP DPAA2.

I managed to compile a small tool of my own using a command similar to the original commands used by DPDK with meson/ninja.

I am having trouble to modify the Suricata building process to make the commands look more like meson/ninja ones.
Are any of you aware of some documentation about building Suricata with DPDK on ARM?

Best regards,
Johan

2

Suricata 7.0 rc 1 has DPDK support. It should not need any build system modifications. Did you try this? If so, can you share the errors and/or more details on the issues you’re seeing?

3

Thank you for your response.

We actually managed to build Suricata using gcc and a handmade linking command.

Meson and ninja in DPDK use a linking gcc command with something like “-Wl,–start-group [many DPDK-related *.a files] -Wl,–end-group”.
I provided a LDFLAGS=“-Wl,–start-group [many DPDK-related *.a files] -Wl,–end-group” to .configure. When compiling Suricata, the libtool command which builds .libs/suricata (which is the file that is installed later on) however uses a a command that looks like “-Wl,–start-group […] -Wl,–end-group […] -Wl,–as-needed -L[many DPDK-related *.a files]”.
I think this is related to libtool behavior. I did not really dig into this yet. I will do it as soon as possible.

4

change configure.ac
CFLAGS=“${CFLAGS} pkg-config --cflags libdpdk”
LIBS=“${LIBS} -Wl,-R,pkg-config --libs-only-L libdpdk | cut -c 3- -lnuma pkg-config --libs libdpdk”

5

Thank you for your answer.

On commit d9e6301 (the one of 7.0.0-rc1), the “DPDK support” part in the configure.ac file looks like:

  • Line 1404: CFLAGS=“${CFLAGS} `pkg-config --cflags libdpdk`”
  • Line 1405: LIBS=“${LIBS} -Wl,-R,`pkg-config --libs-only-L libdpdk | cut -c 3-` -lnuma `pkg-config --libs libdpdk`”

What am I supposed to modify?
Am I supposed to change other lines?

6

Hi Johan,

to make sure I understand - would you like to replace the Suricata Autotools build system with meson and ninja build system?
I am not sure we understand the problem at the moment.
Thanks.

7

Hi Lukas
I do not want to replace the Autotools build system with Meson/Ninja build system.

My issue is that: on my ARM DPDK, it looks like the linking step of an executable that use DPDK seem to need a specific option set provided to gcc during linking. This option looks like “-Wl,–start-group [many DPDK-related *.a files] -Wl,–end-group”.
I actually checked that this option is needed using a small C tool that lists DPDK interfaces. During linking, if I do not use this option with gcc, the tool cannot find my interface. But, if I use this option with gcc, the tool finds my interface.

As I said above, I tried to provide a LDFLAGS=“-Wl,–start-group [many DPDK-related *.a files] -Wl,–end-group” to .configure. When compiling Suricata, the libtool command which builds .libs/suricata (which is the file that is installed later on) however uses a a command that looks like “-Wl,–start-group […] -Wl,–end-group […] -Wl,–as-needed -L[many DPDK-related *.a files]”. I can provide log files for these two steps.
If I manually link Suricata with a custom gcc command that uses the “-Wl,--start-group [many DPDK-related *.a files] -Wl,--end-group” option, Suricata sees my interface.

My goal now is to find a way to make the Autotools build system use the option I need during linking.
I do not plan to make any local modification to the Suricata source code (at least not soon :slight_smile: ), so I could also keep my final custom linking step in the short term. But I am also interested in having a cleaner/simpler compilation process.

Is this explanation clearer?

8

Hi Johan,

thank you, I think I understand your problem.

I’ve tried compiling Suricata on ARM (aarch64) VM and I had no problem with that. I’ve used Ubuntu 22.04 server which had all dependencies installable from the repositories so I’ve only compiled Suricata. I didn’t need to modify anything anywhere.

I think your problem might lie in the installation of DPDK in an unknown location. Did you install DPDK from repositories (dpdk-devel) or did you compile it yourselves? With DPDK you can use pkg-config tool. This tool is also used during configure step e.g. pkg-config --libs libdpdk. Please check if the command outputs something as it is crucial to proceed further.

If you compiled DPDK yourself (and the pkg-config does not recognize libdpdk) then the easiest solution would be to change the installation folder of the DPDK. That can be done with meson during the configuration step of DPDK with --prefix option.

Hope that helps,
Lukas

9

Hi Lukas
Thank you for taking some time to help me.

My ARM board is a SolidRun HoneyComb LX2. The OS image is Debian Bullseye which is built using this Github repo.
As far as I know, the OS image however does not include DPDK files. So I compiled it and installed it locally. The DPDK library is thus installed in my home directory (/home/jmazel/install/dpdk).

“PKG_CONFIG_PATH=/home/jmazel/install/dpdk/lib/pkgconfig pkg-config --libs libdpdk” yields:
-L/home/jmazel/install/dpdk/lib -Wl,–as-needed -lrte_node -lrte_graph -lrte_bpf -lrte_flow_classify -lrte_pipeline -lrte_table -lrte_port -lrte_fib -lrte_ipsec -lrte_vhost -lrte_stack -lrte_security -lrte_sched -lrte_reorder -lrte_rib -lrte_regexdev -lrte_rawdev -lrte_pdump -lrte_power -lrte_member -lrte_lpm -lrte_latencystats -lrte_kni -lrte_jobstats -lrte_ip_frag -lrte_gso -lrte_gro -lrte_eventdev -lrte_efd -lrte_distributor -lrte_cryptodev -lrte_compressdev -lrte_cfgfile -lrte_bitratestats -lrte_bbdev -lrte_acl -lrte_timer -lrte_hash -lrte_metrics -lrte_cmdline -lrte_pci -lrte_ethdev -lrte_meter -lrte_net -lrte_mbuf -lrte_mempool -lrte_rcu -lrte_ring -lrte_eal -lrte_telemetry -lrte_kvargs

If I provide the “PKG_CONFIG_PATH=/home/jmazel/install/dpdk/lib/pkgconfig” variable to the ./configure script, I still get the same linking error as what I explained here. Similarly, my custom linking command is still working.

Does setting up PKG_CONFIG_PATH with a custom value related to the location of the manually compiled DPDK installation on the configure command line was what you had in mind or did I misunderstand you?

Thank you again for your time.
Best regards,
Johan