Thanks, that helps a lot.
Now I’ve encountered a new problem. I am using pcap files to test the multi-threading performance of Suricata with Hyperscan.
And I found that if I use runmode single, one core of my CPU can be fully utilized at 100% occupancy, but when I use the autofp mode and configure multiple cores and threads like this:
threading:
set-cpu-affinity: yes
# Tune cpu affinity of threads. Each family of threads can be bound
# to specific CPUs.
#
# These 2 apply to the all runmodes:
# management-cpu-set is used for flow timeout handling, counters
# worker-cpu-set is used for 'worker' threads
#
# Additionally, for autofp these apply:
# receive-cpu-set is used for capture threads
# verdict-cpu-set is used for IPS verdict threads
#
cpu-affinity:
- management-cpu-set:
cpu: [84-91]
- receive-cpu-set:
cpu: [92-99]
- worker-cpu-set:
cpu: [28-35]
mode: "exclusive"
# Use explicitly 3 threads and don't compute number by using
# detect-thread-ratio variable:
threads: 8
prio:
# low: [ 0 ]
# medium: [ "1-2" ]
# high: ["28-35", "84-91"]
default: "high"
#- verdict-cpu-set:
# cpu: [ 0 ]
# prio:
# default: "high"
#
However, it showed these cores cannot be fully utilized. I want to know why this is happening?
If the receiving thread reaches a receiving bottleneck, how should I configure it?
Thanks!