Suricata and dpdk in secondary mode

Developers
,
1

Hello,
do you have any plans to add the support for dpdk in secondary mode (proc-type=secondary)?

I found this ticket Draft: Introduce support for DPDK secondary mode for workers runmode and DPDK Prefilter by lukashino · Pull Request #7818 · OISF/suricata · GitHub, is it in roadmap?

Best regards,
Daniele

2

Hi Daniele,

welcome to the community!

I can say secondary mode is not within near-future roadmap or noted anywhere officially but I would like to have it supported in Suricata. There hasn’t been any public annoucement when that would be added to Suricata but community can drive the roadmap of Suricata a lot. I’ve been bouncing between that and other things for some time. However, since whole DPDK is quite a new feature, I think we will want to focus on stabilizing 7.0 first before adding more.

From what I remember when I was doing the PR last time, we were missing a way how to test it - ideally with native DPDK apps. I’ve suggested a possible solution here (w/ dpdk-testpmd) but if you have more to add please do so in the redmine ticket

Also, the last version of the work is here:

Secondary works there and in the dpdk folder there is also a prefilter app that can serve as the primary app and pass network traffic to Suricata.

Lukas

3

thank you.

I need to introduce Suricata with dpdk support on a system where there is already a dpdk instance running.

First of all I would like to understand if I’m looking in the right direction: in this kind of scenario I supposed that the best (only?) solution would be to have Suricata\dpdk in secondary mode.

Is it correct?
Do you have any other strategies to handle this scenario?

4

If you only need to run Suricata on an instance where a DPDK application is running and Suricata and the other application don’t need to be connected then you can use EAL argument --file-prefix which creates something like different userspace for your other application.

https://doc.dpdk.org/guides/linux_gsg/linux_eal_parameters.html

So you run it as:
dpdk-testpmd -a 0000:7e:00.0 --file-prefix=app1 -l 0,1 -- -i

and the other app as:
dpdk-testpmd -a 0000:3b:00.0 --file-prefix=app2 -l 2,3 -- -i

Note: This relies on the fact that with each application you want to handle separate network interfaces.

5

thank you Lukas,
but in my system I need to have the Dpdk instance and Suricata connected to the same interfaces, so, basically, you confirm that the only way is to have Suricata (with dpdk enabled) in secondary mode, isn’t it?

I don’t know if there are any other alternatives strategies to avoid that Suricata and the Dpdk share the interfaces.

For example, I’m evaluating to create virtual devices, handled by Suricata, connected (with tap) to the real interfaces handled by the original Dpdk instance, but it’s not clear to me if it is possible to split the interfaces in this way and if it make sense to enable the dpdk on Suricata in such internal topology.

I suppose also that it would be better for the performance and the resources consumption to avoid to have 2 dpdk instances.

Best regards,
Daniele

6

So you say, you have let’s say one interface from which you want to pass packets to both/multiple applications?

Then I can think of deploying OVS or VPP. It makes deployment of such applications more manageable but it definitely takes some toll on the performance - and my knowledge there is somewhat limited there.

I imagine your topology like this:

[IF] -> DPDK_APP1
     -> DPDK_Suricata

virtual devices, handled by Suricata, connected (with tap) to the real interfaces

I do not think there is such a thing as a software TAP in the DPDK natively. That TAP functionality must be provided by some application. And that can be e.g. OVS. OVS most likely will need to do 2 packet copies where each copy will be forwarded to the individual application.
Note the application runs in parallel.
Note2: I’ve found this 55.2. Multi-process sharing in https://doc.dpdk.org/guides/nics/tap.html but I have never tried so cannot really speak much about it.

[IF] -> OVS -> DPDK_APP1
            -> DPDK_Suricata

Alternatively, you could do a hardware TAP if possible and use 2 interfaces (if you have access to HW and have a spare port). I believe that can lead to easy software architecture and good performance.

The secondary mode can be useful on topology like where you would use net_ring virtual device to connect two applications together. This in contrast to the OVS solution would make the applications run in a pipeline (where the slowest app would slow down the whole pipeline of applications but on the other hand - no packet copies would happen).

[IF] -> DPDK_APP1 -> DPDK_Suricata

So my suggestion:

  • look if a hardware TAP is possible
  • look at OVS/similar applications for distributing packets between applications
  • try the secondary mode branch from my repo that was suggested earlier
7

Hi Lukas,
many thanks for your feedback.

Yes, the first application is OVS with DPDK.
Have you ever tested OVS\dpdk with Suricata\dpdk?

is it possible to apply this schema in IPS inline mode?
I would think to something like this:
[IF] → OVS → DPDK_APP1 → `DPDK_Suricata → …

and I was thinking to attach Suricata to a tap device
[IF] ↔ [OVS\DPDK] - [TAP] ↔ `Suricata ↔ …

but it is not working. In my system I can use tap and OVS with or without dpdk, that’s usually not a problem.
Do you know if Suricata supports tun\tap devices?
From my test it doesn’t seem to work even in a “normal” environment without dpdk.

TAPI hardware is not possible.

I’m testing your branch.