What DYNANIC brings to SuriCon 2026 in Lisbon?

What we will show in Lisbon : Suricata Turbo

Suricata Turbo is an open-source fork of Suricata that extends its DPDK capture path with hardware flow offload. Suricata policy determines which traffic no longer needs further inspection; the NIC enforces the corresponding filter through the standardized DPDK rte_flow API. Application developers do not need to write custom FPGA code. Deployment does require a compatible NIC and driver, together with a DPDK-enabled build of Suricata Turbo. The implementation is available on GitHub or you can see the DYNANIC whitepaper:

It works on two levels.

Static offload. Operators define testpmd-style match patterns in the Suricata YAML configuration. Suricata Turbo installs matching drop filters on supported NICs at startup, before packets enter CPU receive queues. Matches can use flow fields, VLAN identifiers, and protocol fields, subject to the specific NIC and driver capabilities. DYNANIC has also proposed the extracted testpmd flow parser as a reusable DPDK library. For illustration, an explicitly approved test source could be filtered with:

Typical static use cases are management VLANs, backup replication streams, and known infrastructure traffic.

Dynamic offload. This path hooks into Suricata’s native bypass API. When a flow worker determines that a flow meets a configured bypass policy, it places a request on a DPDK ring buffer and immediately resumes packet processing. A separate bypass manager thread drains the queue and programs rte_flow rules sequentially. The worker does not wait for NIC rule insertion. After successful rule creation, the hardware flow handle is linked to Suricata’s software flow entry.

Dynamic offload installs 5-tuple flow matches. Supported policies include post-handshake TLS/QUIC filtering, elephant-flow thresholds based on bytes or packets, and subnet allowlisting. The YAML configuration or Suricata ruleset determines what qualifies; allowlists can be reloaded through Suricata’s Unix socket without restarting the engine.

Visibility and fallback. For dynamically offloaded flows, hardware rules can use COUNT+DROP actions, preserving flow-level traffic statistics associated with Suricata’s software flow table. This is not continued packet-content inspection: after offload, the filtered packets no longer reach the CPU. Static filters likewise exclude their matching traffic before Suricata creates application-level observations. If the NIC flow table fills, new dynamic requests fall back to software bypass and Suricata exposes this through counters. Hardware capacities vary, from roughly 65,000 to millions of rules. Suricata Turbo has been validated on NICs from Intel, NVIDIA, and DYNANIC.

From commodity NICs to 400G on FPGA

The Suricata Turbo approach is not limited to FPGAs: it uses supported rte_flow features on compatible Intel and NVIDIA NICs as well as DYNANIC hardware. Separately, DYNANIC’s FPGA platform provides a programmable 400 Gbps packet-processing pipeline and hardware flow tracking behind the same software-facing API. Rule capacity, actions, and throughput depend on the actual card and deployment profile.

In Lisbon we will show the 400G Suricata IDS acceleration setup with a Silicom ThunderFjord SmartNIC, based on an Altera Agilex FPGA, and four TRex traffic-generator instances.

• In the static-filter scenario described in the 400G demo, approximately 250 Gbps of generated HTTPS traffic on TCP port 443 was filtered at the NIC, while about 30 Gbps of selected HTTP traffic was delivered to the host for Suricata processing.
•  In the dynamic scenario, Suricata identified encrypted traffic on non-standard ports, then offloaded approximately 50,000 selected flows through hardware rules. Hardware counters retained flow-level statistics; offloaded packet payloads were no longer deeply inspected by the CPU.

These figures describe a specific traffic mix, not 400 Gbps of full payload inspection by CPU cores. We reported approximately 70% lower CPU load for the demonstrated inspection path and an illustrative deployment comparison of four accelerated servers versus 20 conventional servers. The associated five-year cost model was $200,000 versus $800,000 (75% lower). Outcomes depend on traffic mix, bypass policies, NIC capabilities, rulesets, and cost assumptions.

At SuriCon, we also hope to exchange ideas about how programmable NICs could complement future acceleration stages, including DPI pattern matching.

Who is DYNANIC solution for?