Packet Acquisition via DPDK Rings

jack327 · June 30, 2022, 1:53am

If I had a software environment that utilized DPDK to read packets directly off a NIC, and this system operated as the DPDK primary, configured the NIC, and retrieved packets, would I be able to pass packets to Suricata (version 7.0) via DPDK as well? Does Suricata support receiving packets from a ring instead of a NIC?

Additionally, Suricata is intended to run as a primary process only.

(From near the end of this: 10.1. Suricata.yaml — Suricata 7.0.0-dev documentation)

This piece of the documentation makes it sound like it won’t work, but I just wanted to confirm.

Thanks!

vjulien · July 2, 2022, 5:26am

This is in development:

github.com/OISF/suricata

Draft: Introduce support for DPDK secondary mode for workers runmode

OISF:master ← lukashino:feat/5203-primary-app-v2

opened 09:16AM - 27 May 22 UTC

lukashino

+6390 -266

- [X] I have read the contributing guide lines at https://redmine.openinfosecfou…ndation.org/projects/suricata/wiki/Contributing - [X] I have signed the Open Information Security Foundation contribution agreement at https://suricata.io/about/contribution-agreement/ - [X] I have updated the user guide (in doc/userguide/) to reflect the changes made (if applicable) Link to [redmine ticket about Suricata secondary process support](https://redmine.openinfosecfoundation.org/issues/4910). Link to [redmine ticket about prefilter application](https://redmine.openinfosecfoundation.org/issues/5203). This is a follow-up of #7283 which incorporates two Redmine tickets together, one for Suricata secondary mode support and the other for adding an app that would run as a primary process. The PR extends the work of #7283 by continuing in reaching the prefilter concept. As of now, the prefilter configures the provided NICs according to the YAML configuration and then passes packets to Suricata through DPDK rings. It also uses a message system between Suricata and Prefilter for asynchronous bypass method. Suricata can also load Prefilter configuration by reading Prefilter's shared configuration stored in a memory zone. The prefilter is intended to be architecturally flexible (not depending on any hardcoded module) but as of now, for some use-cases, the prefilter uses Suricata library. Use flags `--enable-dpdk --enable-dpdk-apps` to enable Prefilter in the configuration process. The plan is to have a shared DPDK configuration codebase for prefilter and Suricata. As of result, prior to the compilation of the prefilter app, Suricata needs to be first compiled and installed (together with headers and library). Makefile target `dpdk-apps-prereq` should solve the issue. After the Suricata library is installed, it needs to be added to the list of shared libraries (ldconfig) or at least edit `LD_LIBRARY_PATH` variable. Makefile target `dpdk-apps` compiles the prefitler app. The final `prefilter` binary can be found in `dpdk/prefilter/build` folder. Changelog from #7283: - new asynchronous bypass support through message mechanism - Suricata reading Prefilter configuration from a shared configuration memory zone - bug fixes

Testing/feedback would be much appreciated!

jack327 · August 8, 2022, 10:31pm

Finally getting back around to this work.

Since we already have a primary process in control of the packets from the NIC, we don’t want to share access to the NIC with any other processes. To this end, we found the DPDK MemIF driver that has both sides of the connection run as primary and would allow us to send the packets from our main process into Suricata and possibly decide which packets make it to Suricata if we want.

We’ve successfully gotten Suricata to receive from one of these memory interfaces on one thread, but for some reason multiple threads don’t work well with memif in our first attempts. I’m continuing to explore whether I can get multithreaded access to these memory interfaces to work as I want them to.

Separately, why is autofp not available on DPDK? I can start digging into it too, but I’m curious if there’s some terrifying pitfall behind why it’s not supported already. If we need more than one memory interface, it would make sense to make as many memory interfaces as packet acquisition threads.

lukashino · September 6, 2022, 3:47pm

Hi @jack327,

I believe the use-case you are describing (with having your primary application and distributing traffic to multiple Suricata workers from the primary application) is similar if not the same concept which was described at Suricon 2021 - Using DPDK Prefilters to accelerate Suricata. This is being implemented and currently is in Draft: Introduce support for DPDK secondary mode for workers runmode and DPDK Prefilter by lukashino · Pull Request #7818 · OISF/suricata · GitHub

The work adds support for running Suricata workers as a secondary process and receive packets from the primary application through DPDK rings. This would also cover your autofp usecase where some cores of the primary process would receive packets from the NIC and forward these packets to Suricata where the number of primary and secondary can be different.

The PR already contains README with build and configuration instructions on how to get DPDK Prefilter (autofp mode) up and running.

Let me know if you get stuck at something. Feedback is very much appreciated.