Multi-core analysis processor: spreading captured network traffic across CPU cores for protocol analysis without splitting a flow
The many-core processing side of a network protocol analyzer or capture appliance · symmetric flow hashing so each connection stays on one core, RSS queues and NUMA placement, and capture NICs that hand traffic to up to 128 streams
Protocol analysis costs processor time for every packet, and once one core is saturated the work has to be spread. The analyzer therefore runs on multiple cores, but it can only do that if the traffic is divided so that each connection is seen whole by one core. This page is about that processing side of an analyzer or capture appliance: how flows are hashed to cores, how cores, queues and memory are placed, and what a capture NIC takes off the CPU.
The multi-core processing stage of network protocol analyzers, intrusion detection sensors and packet-capture appliances: flow-based distribution of captured traffic to cores (symmetric hashing, RSS queues, fanout groups), placement of worker threads and NICs on NUMA nodes, and capture NICs that deliver flows to up to 128 host streams. Rugged box and panel PCs for machines are covered on the Industrial computer page; modular edge computers on the Modular industrial edge computer page; real-time soft-PLC controllers on the Control computer for real-time machine control page; FPGA devices as components on the Field-programmable gate array (FPGA) page; Ethernet switches on the Industrial Ethernet switches page. The portable analyzer instrument as a whole, with its ports, decodes and load tests, is covered on the Multi-protocol network protocol analyzer page; RF vector network analyzers are a different instrument with their own page.
CNFX editorial research · Sources checked October 12, 2026 · 3 sources
Both directions of a connection on the same core: symmetric flow hashing
Zeek's cluster documentation states the starting point plainly: Zeek is not multithreaded, so once one core is saturated the only option is to spread the work over more cores or computers, with a frontend that splits traffic into streams or flows. [2] The split has to be by flow, and symmetric, so that client-to-server and server-to-client packets of one connection reach the same worker.
Suricata warns that some NICs, pointing to lower-end 1 Gbit/s cards, do not support symmetric hashing; for those it suggests a single combined queue with af-packet's cluster_flow mode, to avoid out-of-order packets. [1] Zeek notes that some Linux kernels between 3.10 and 4.7 may have a bug that prevents the symmetric hashing its fanout relies on. [2]
Editorial note: a hash that is not symmetric sends the two directions of a TCP connection to different cores, and neither core can reassemble the session; ask the supplier how the analyzer's distribution is made symmetric, and how it was verified at the traffic mix you expect.
Where the flow split is made
Published example
Discrete hardware balancer
cPacket devices rewrite the destination MAC so every packet of a flow gets the same one; each worker then filters its own stream [2]
Kernel fanout group
Two or more Zeek workers on one interface join an AF_PACKET fanout group (default id 23), load-balanced by symmetric flow hashes; two workers each see about half the traffic [2]
NIC RSS queues
Suricata on Intel x710 or Mellanox ConnectX-5: more RSS queues with a low-entropy Toeplitz key for symmetric hashing, cluster_qm mode so all packets of one queue go to one socket [1]
Capture NIC streams
Napatech: flow identification by protocol-specific or custom hash keys, distributed over up to 128 Rx streams [3]
Give the supplier the link speeds and number of ports, peak and average traffic, the protocols to be decoded, whether both directions arrive on one port or two, and the analysis software to be run.
02
Cores, RSS queues and NUMA nodes: 16 queues, 36 workers on one node of a 72-core host
Suricata's high-performance guide shows how worker threads are matched to NIC queues and placed on the processor that holds the NIC. [1]
The guide recommends, where there is more than one NUMA node, using one worker thread for each core available on the same NUMA node, and putting Suricata and the capturing NIC on the second node because Linux services use CPU 0; it also says irqbalance should be stopped. [1]
Editorial calculation: 2 sockets × 18 cores × 2 threads = 72 logical CPUs, so the 36 workers are exactly one socket's worth; in the AMD example, cores 1–7 and 64–71 are 7 + 8 = 15 CPUs for the 15 RSS queues, and CPUs 8–55 are 48 CPUs for the 48 workers. [1]
Editorial note: when a vendor quotes an analyzer's core count, ask how many cores sit on the NUMA node attached to the capture NIC; cores on the other socket reach the packets across the inter-socket link.
NIC and Suricata on NUMA node 1; 36 worker threads, 18 per af-packet interface, on CPUs 18–35 and 54–71 [1]
AMD EPYC 7601 host (32 cores per socket, 2 threads per core)
15 RSS queues pinned to cores 1–7 and 64–71 on NUMA node 0 where the NIC sits; 48 worker threads on CPUs 8–55, cluster_flow [1]
03
What a capture NIC takes off the cores: 128 Rx streams, 1 ns time stamps and 16 MB to 1 TB host buffers
Napatech's SmartNIC feature overview describes capture hardware that delivers packets to the host already sorted by flow and time-stamped, with zero-loss capture for all frame sizes and almost no CPU load claimed for its Link-Capture software. [3]
Napatech explains that its host buffers place packets back to back in large memory buffers, so only the first access waits on external memory and the following packets are already in level 1 cache when the CPU needs them; applications needing low latency can take small chunks with an optional maximum latency, others large chunks for more efficient processing. [3]
Editorial note: "zero loss" and "almost no CPU load" are the vendor's descriptions; ask for the frame-size, port-count and stream-count conditions under which a capture NIC and analyzer combination was tested, and what the analysis software itself drops at full load.
Napatech SmartNIC feature
Published value
Flow distribution
Over up to 128 Rx streams per SmartNIC; 128 Tx streams [3]
Hash keys
Multiple protocol-specific, custom and dynamically selected [3]
Time stamps
Start- or end-of-frame, 1 ns resolution; UNIX formats at 1 or 10 ns, PCAP formats at 1 or 1,000 ns [3]
Holds packets during micro-bursts or PCI Express congestion [3]
Port merging
Packets from multiple ports, or multiple SmartNICs, merged into one stream so both directions of a connection can be analysed together [3]
04
What to send for a multi-core analysis processor
Paste it into your enquiry below or into an email to a maker, then replace every bracket.
Links: [ports; speeds; peak and average traffic]
Traffic: [protocols to decode; both directions on one or two ports]
Software: [analyzer or IDS; threads per core]
Distribution: [NIC RSS, capture NIC streams, external balancer; symmetric]
Platform: [sockets; cores per NUMA node; memory]
Capture: [time stamp resolution; buffer size; storage to disk]
Acceptance: [loss test conditions]
Explore company information and manufacturing capabilities, then discuss the scope of your project with a relevant supplier.
Share this page
Compiled and source-reviewed by the CNFX editorial team.
Each manufacturer above links to the page on that company's own website where the product is listed, with the date we checked it. How we source and review
· Page last updated 13 October 2026
Buyer questions
Why must flow hashing be symmetric for protocol analysis?
So that both directions of a connection reach the same worker; Zeek's AF_PACKET load balancing uses symmetric flow hashes, and Suricata uses a low-entropy Toeplitz key to make NIC RSS symmetric. [2][1]
How many worker threads should a packet analyzer use?
Suricata's guide recommends one worker thread per core available on the NIC's NUMA node, for example 36 workers on one node of a 72-logical-CPU, two-socket host. [1]
Can Zeek use more than one core?
Zeek's main event loop is single-threaded, so it runs multiple worker processes, each on its own core, behind a flow-based load balancer. [2]
What does a capture SmartNIC add?
Napatech lists flow distribution over up to 128 Rx streams, 1 ns time stamps, host buffers of 16 MB to 1 TB and onboard buffering for bursts. [3]
Sources and what still needs a direct check
Sources checked 2026-10-12. Flow distribution, RSS queues and NUMA placement come from the Suricata user guide (OISF) and the Zeek cluster documentation; capture NIC streams, time stamps and buffers from Napatech's SmartNIC feature overview.
