Feature #269
closed
Added by Benjamin Flament almost 14 years ago.
Updated over 13 years ago.
Description
I'm currently testing suricata for a project where we need it to stand high throughputs. Our current goal is to get to 1Gbps in inline mode, but when I run it with 1Gbps of traffic, the queues get full and packets are dropped. Observing the CPU consumed by each thread I noticed that the veredict thread was almost consuming an entire core of the CPU, which makes me think it may be the problem. I also tried to run 2 instances of suricata and splitted the traffic in two (almost equal) queues based on packets source IP and got it running with no problem.
I suspect the problem may be the RecieveNFQ or Veredict Thread as 1 proccess by itself couldn't handle all the traffic and the CPU was still running at half capacity. Would it be possible to have various ReceiveNFQ and Veredict threads so that their load is shared by many cores?
Files
- File multiqueue.tgz added
Benjamin Flament wrote:
I'm currently testing suricata for a project where we need it to stand high throughputs. Our current goal is to get to 1Gbps in inline mode, but when I run it with 1Gbps of traffic, the queues get full and packets are dropped. Observing the CPU consumed by each thread I noticed that the veredict thread was almost consuming an entire core of the CPU, which makes me think it may be the problem. I also tried to run 2 instances of suricata and splitted the traffic in two (almost equal) queues based on packets source IP and got it running with no problem.
I suspect the problem may be the RecieveNFQ or Veredict Thread as 1 proccess by itself couldn't handle all the traffic and the CPU was still running at half capacity. Would it be possible to have various ReceiveNFQ and Veredict threads so that their load is shared by many cores?
I've submitted a patchset (currently under review) that provides multiqueue capability to suricata. By this I mean you can use a command like suricata -c suricata.yaml -q 0 -q 1
to run suricata on queue 0 and 1 (number of queues is hard coded to 16).
I attach to this ticket a patchset over current git master if you want to test it. This patchset contains two things:
- A work on cpu affinity setting (you can choose on which core a specific task will run)
- the support for multiqueue
- File deleted (
multiqueue.tgz)
- Status changed from New to Closed
Closing as there has been no feedback to Eric's solution. Please reopen if you still see the issue.
Also available in: Atom
PDF