what is the difference between DPDK_SURICATA-4_1_1 and DPDK-Suricata_3.0?

[vipinpv85]

what is the difference between DPDK_SURICATA-4_1_1 and DPDK-Suricata_3.0?

[vipinpv85]

3.0 is done.
4.1.1 is work in progress

[ahubaoan]

I found out that you commented on the function rte_eal_remote_launch(), why?

I think about whether this method works:

1. Modify dpdk code to support symetric-RSS, like https://haryachyy.wordpress.com/2019/01/18/learning-dpdk-symmetric-rss/
2. Each nic RX QUEUE is bound to a thread
3. Modify suricata, bind each worker's thread loop function to dpdk thread with rte_eal_remote_launch instead of creating a thread in suricata.

Or more aggressive, still open threads in the worker, each thread to fetch data in the corresponding dpdk queue, instead of using ap_k eal_thread

[vipinpv85]

I found out that you commented on the function rte_eal_remote_launch(), why

please do analysis and share me the reason why I have done the same.

I think about whether this method works:

1. Modify dpdk code to support symetric-RSS, like https://haryachyy.wordpress.com/2019/01/18/learning-dpdk-symmetric-rss/
   If you can get cpu hash faster than nic hardware please share your findings.

2. Each nic RX QUEUE is bound to a thread
   Already explained bottle neck is suricata stages

3. Modify suricata, bind each worker's thread loop function to dpdk thread
   Yes, that is already done

with rte_eal_remote_launch instead of creating a thread in suricata.
😀 Please think or try and let me know why it is not a good idea

Or more aggressive, still open threads in the worker, each thread to fetch data in the corresponding dpdk queue, instead of using ap_k eal_thread
This is clear indication you have not gone through the wiki or code changes. If you closely checked the readme figure you will know why it is not so.

[vipinpv85]

@tolunFdancer tolunFdancer I have to assume the title is your question what is the difference in DPDK suricata 3.0 vs 4.1.1?

Answer>

DPDK suricata 3.0 is
1. proof of concept to run with DPDK thread
2. tested on host and guest os with Intel NIC
3. DPDK version 2.0, 2.1 and 17.11
4. fixed EAL args
5. primitive zercopy
6. Support for reassembly is not done in DPDK
7. Primitive rule check
8. 1 RX threads for multiple nix

DPDK suricata 4.1.1 is
1. DPDK version 18.11.1
2. Suricata version 4.1.1
3. Support for differnt vendor NIC.
4. Use of flexible EAL args 
5. to do: reassembly, pre acl, flatten buffer, external buff, Flow caching
6. work in progress: multiple RX for NIC -Queue pair
7. Extra: hybrid IDS|IPS

[tolunFdancer]

I want to use suricata as IDS with dpdk to capture and parse packets, which one should I choose? 4.11 or 3.0?

[ahubaoan]

Does 4.1.1 completed and could used to product enviroment? Thank you!

[vipinpv85]

It is not complete. Work in progress in spare. Appreciate help in design, coding and testing.

[vipinpv85]

@ahubaoan are there any plans from your end to design, contribute or test the same?

[ahubaoan]

Why not use dpdk-symmetric-RSS directly?
for muti-RX thread and suricata run as worker mode

[vipinpv85]

Why not use dpdk-symmetric-RSS directly?
for muti-RX thread and suricata run as worker mode

I am not convinced with this approach, because

1. Creating symmetric RSS and spreading the workload to multiple queues is useful if the task is to receive packets and do the process in same instance.

2. One would require additional threads, to do an activity.

ie: if there is 10G interface and 4 RX queues in ideal world you would get 2.5G per interface by using 4 RX threads. But each CPU core tuned propelry can do around 25 to 30G RX burst. So one is wasting the potential by spreading on RSS in DPDK RX mode.

@ahubaoan Can you share your plan of work from your end? Are planning to design the feature list, design to-do list, or contribute by testing? Please let me know at earliest as I am waitign for your inputs before starting 2nd phase.

[ahubaoan]

I am not familiar with dpdk, but after understanding it, I know that dpdk has the advantage of reducing cpu interrupt, zero copy, and cache miss to improve performance.

If we can handle the entire stream through one thread, ie:
               [DPDK receive -> suricata worker]
Whether these advantages can improve the overall speed:
A.use suricata worker mode, do not need any thread lock
B.hash at dpdk, it is very fast
C.zero copy form dpdk
D.most nic driver has 32/64 combined, in most cases my cpu is 32 threads or 64 threads, exactly match

I am trying to make a simple IDS based on suricata, but the af-packet that comes with suricata is too slow, pf_ring and netmap are not very friendly (personal), looking for a more suitable packet driver

[vipinpv85]

A.use suricata worker mode, do not need any thread lock
[VV] this is done

B.hash at dpdk, it is very fast
[VV] asking NIC to do RSS hash is faster than CPU hash.

C.zero copy form dpdk
[VV] currently DPDK-Suricata is zero copy mode.

D.most nic driver has 32/64 combined, in most cases my cpu is 32 threads or 64 threads, exactly match
[VV] NIC can have upto 128 RX queues per port also, but it is driver which decides how many RX queues are to be activated. Similar to this, DPDK application controls how many RX queues are to be activated.

I am trying to make a simple IDS based on suricata
[VV] this is already done

but the af-packet that comes with suricata is too slow,
[VV] performance comparision with 4*1G NIC and 3 CPUrunning DPDK-SURICATA is present in wiki page.

pf_ring and netmap are not very friendly (personal), looking for a more suitable packet driver
[VV] I am not sure what is your ask is here, Packet side problem is solved with the current commits into DPDK-Suircata. If you have better ways please suggest I can think about it.

@ahubaoan Can you share your plan of work from your end? Are planning to design the feature list, design to-do list, or contribute by testing? Please let me know at earliest as I am waiting for your inputs before starting 2nd phase.
[VV] I will not make this request any more I will work on the feature list to implement.

[ahubaoan]

First of all, thank you for answering my question all the time.

I just want the easiest and quickest way to make a DPDK+suricata IDS

Your DPDK-Suricata_3.0 version has implemented most of the features, but I found that your DPDK-Suricata_3.0 version seems to only use one thread. Although it runs in woker mode, the whole stream is only one thread and cannot use CPUs completely. Why not do multithreading directly， just like one thread bind one(or 2) NIC combined and one worker ?

[vipinpv85]

@ahubaoan it is clear from the above

First of all, thank you for answering my question all the time.

I just want the easiest and quickest way to make a DPDK+suricata IDS

Your DPDK-Suricata_3.0
[VV] Suricata version ported 3.1.2

version has implemented most of the features, but I found that your DPDK-Suricata_3.0 version seems to only use one thread.
[VV]This is not correct understanding.

Although it runs in woker mode, the whole stream is only one thread and cannot use CPUs completely.
[VV] if you are talking about Suricata worker mode, please read https://suricata.readthedocs.io/en/suricata-4.1.3/performance/runmodes.html and please check CPU category in suricata.yaml to configure number of mgmnt, and worker threads.

Why not do multithreading directly，
[VV] I think you have read the link I was referring earlier. please read https://xbu.me/article/performance-characterization-of-suricata-thread-models/ for a 3rd party testing.

just like one thread bind one(or 2) NIC combined and one worker ?
[VV] It looks like you have not explored the wiki pages for the project, which showcases the performance drop is due to worker model

1. https://www.slideshare.net/vipinpv85/dpdk-frame-pipeline-for-ips-ids-suricata
2. https://www.slideshare.net/vipinpv85/porting-idsips-to-work-with-dpdk

[vipinpv85]

@ahubaoan I ma happy if you are willing to contribute to your design as you suggested as

DPDk Phycial NIC ==> DPDK RX thread (RSS) ==> multiple worker.

But please refer to the following.

1. Receive Side Scaling is a technique used by network cards to distribute incoming traffic over various queues on the NIC. This is meant to improve performance but it is important to realize that it was designed for normal traffic, not for the IDS packet capture scenario. from https://suricata.readthedocs.io/en/suricata-4.1.3/performance/packet-capture.html

2. on i40e (fortvillw) Generic: set RSS queues to 1 or make sure RSS hashing is symmetric. Disable NIC offloading. as per https://suricata.readthedocs.io/en/suricata-4.1.3/performance/packet-capture.html

based on your previous question hey, have not thought of HW RSS or core pining according to user
[VV] yes,

Possible next question from your end: Ok Vipin, these information are helpful and I understand why you started with worker mode. But can not we do auto-fp mode for DPDK
[VV] yes, we can. Will you like to contribute by designing, coding, testing? (i have not recieved your answer yet).

If above all are agreed, but still if you have a question like I just want the easiest and quickest way to make a DPDK+suricata IDS, but with RSS to spread to multiple autofp
[VV] Please refrain from using the same as it is not implemented. if you can implement please do and if you are interested to share back whatever help you got from this project please share.

[vipinpv85]

If the plan is share ideas, please use the template and raise in right forum. If these are arguments plaese support with proof.

[vipinpv85]

@ahubaoan Have you found the answers to update us all?

[vipinpv85]

Answer to the query why can not one use 5 tuple symmetric hash is because all fragments other than 1st packet the 5 tuple is absent making 3 tuple unusable for symmetric RSS.

As I am not able to see any updates from @ahubaoan, I am assigning the task of updating this repository with the code of implementing SW or HW Symmetric Hashing for reassembled packets. to @ahubaoan with current deadline of the end of December 2019. Please do contact me if you need more time.

[vipinpv85]

I found @ahubaoan updates in other repository for dpdk-suricata. Which means you are still active. Least update us all with progress and early patch.

[vipinpv85]

based on the @ahubaoan comments, no contribution to this repository targeted emails, I have decided not to wait for @ahubaoan suggestions as git merge request.

Have completed the functional logic with the performance of each worker thread around 1 million packets per sec. @tolunFdancer you can try the same.