On this page
Key points
- State the measurement layerIP bytes, Ethernet frames and wire occupancy produce different Gbit/s figures.
- Inspect individual queues and coresA low machine-wide CPU average can hide an overloaded part of the receive path.
- Qualify the real policyForwarding, dropping, tracking state and inspecting traffic are different workloads.
Small packets can expose a different limit
A high packet rate means many receive, parse, lookup and forwarding decisions per second. Depending on the implementation, some decisions run in hardware and others consume CPU, memory bandwidth or shared state. Small packets can expose a packet-processing limit before the nominal link bandwidth is full.
The symptom alone does not identify the limiting component. Loss might occur at the upstream handoff, NIC queue, worker, state allocation or output link. Locate the first failing stage before changing hardware or choosing another filtering framework.
Relate Mpps to a clearly defined frame size
For nominal Ethernet wire occupancy in one direction, use Gbit/s = Mpps × (frame bytes + 20) × 8 / 1000. Here the frame includes FCS; the extra 20 bytes account for preamble and inter-frame time. This is an accounting model, not an achieved filtering benchmark.
A capture may omit FCS, and an IP counter excludes Ethernet overhead. Write down what your graph counts before comparing it with the model. The examples below do not include a separate PHY/FEC calculation or a claim that a real interface can sustain the theoretical maximum.
| Frame including FCS | At 10 Mpps | Nominal maximum on 100 Gbit/s |
|---|---|---|
| 64 bytes | 6.72 Gbit/s | 148.81 Mpps |
| 128 bytes | 11.84 Gbit/s | 84.46 Mpps |
| 512 bytes | 42.56 Gbit/s | 23.50 Mpps |
| 1518 bytes | 123.04 Gbit/s | 8.13 Mpps |
Reduce work before the exhausted stage
If upstream bandwidth is exhausted, move the reduction upstream or change the delivery design. If local processing is the measured limit, investigate supported early filtering, queue configuration, worker placement and the cost of the intended rules. A later drop cannot undo work already performed earlier in the path.
XDP, a DPDK application, VPP and a device ACL are different execution environments, not universal performance rankings. Compare the required policy and actual hardware. Record parser support, state behavior, update handling and what happens when a feature is unavailable or a process stops.
Measure distribution, not just totals
Receive-side scaling commonly hashes packet-header fields to queues. Many flows may distribute well, while a different traffic mix can concentrate work. A single busy receive queue or worker can drop traffic while the machine-wide CPU average remains modest. Check the actual mapping and per-queue counters rather than assuming more cores create equal sharing.
Include NUMA locality, NIC placement, PCIe capacity, worker pinning and transmit queues in the record. Their effect depends on the platform and implementation. Do not copy a tuning recipe without measuring the existing path and retaining a reversible configuration.
Example: 100 Mpps leaves little room for an unclear claim
At 64-byte Ethernet frames, 100 Mpps represents 67.2 Gbit/s of nominal wire occupancy. At 1518-byte frames, the same packet rate represents 1230.4 Gbit/s. A claim of “100 Mpps” without frame size, direction and workload is therefore incomplete.
For a hypothetical two-node deployment, do not simply divide the offered traffic by two. Test the steering method and uneven distribution, then the failure condition the service must tolerate. If all protected traffic can move to one surviving node, that node and its receiving links need a separately qualified envelope.
Build a reproducible capacity record
Describe the system
Record NIC, firmware, driver, CPU, memory, NUMA layout, software versions, ports and enabled functions. State whether results concern one direction or an aggregate.
Describe the traffic
Record frame sizes, protocols, flow count, state creation, legitimate-to-unwanted mix and duration. Use an authorized isolated setup with synchronized measurements.
Measure useful forwarding
Collect offered, dropped and forwarded packets at named points. Also record legitimate transaction success, latency and loss; a fast drop-only result is not a stateful forwarding result.
Find and verify the operating margin
Test the intended load, controlled changes and the specified failure case. Keep the production operating envelope below the demonstrated limit and document the selected margin.
Read graphs in their operational context
- Do not combine receive and transmit rates and present them as one-way ingress capacity.
- Do not infer the busiest second from a five-minute average or a billing percentile.
- Do not assume sampled flow data captures every short burst or gives the same counter as the NIC.
- Do not call dropped packets “clean traffic processed” without stating what processing occurred.
- Do not treat a successful large-frame test as evidence for minimum-frame packet capacity.
Turn a benchmark into a useful sizing decision
Keep theoretical wire limits, measured dataplane capacity and application results in separate fields. When a measurement is missing, leave it unknown. A calculator can check arithmetic and link constraints, but only a relevant test can qualify the filtering system.
Questions and answers
Is a high Gbit/s figure enough to size a filter?
No. Packet size, packet rate, policy, state creation and distribution affect the workload. Measure the configuration that will actually run.
Does low total CPU mean the server has headroom?
Not necessarily. A queue, worker, memory path or external link can be the bottleneck while other cores remain idle.
Can the theoretical Ethernet rate be sold as filtering capacity?
No. It is a wire-occupancy limit under stated assumptions. A product capacity claim needs measurements for the relevant traffic and enabled features.
