The FFPF architecture is arguably more complex than many of its competitors. A possible consequence of increasing expressiveness may be a decrease in performance of simple tasks. To verify FFPF's applicability in the general case we have directly compared it with the widely used Linux socket filter (LSF), by running identical queries through (a) libpcap with Linux' LSF back-end, and (b) libpcap based on an FFPF implementation. We realise that for various aspects of filtering faster solutions may exist, but since the number of different approaches is huge and none would be `obvious' candidates for comparison, we limit ourselves to the most well-known competitor and compare under equivalent configurations (using the same BPF interpreter, buffer settings, etc.).
To show their relative efficiency we compare the two packet filters'
CPU utilization (system load) using
OProfile4. Since packet
filtering takes place at various stages in kernel and userspace, a
global measure such as system load can convey overall processing costs
better than individual cyclecounters. Results of subprocesses are
discussed using clockcycle counts later on. Both platforms have been
tested with the same front-end,
tcpdump (3.8.3). Use of the
BPF interpreter was minimized as much as possible: only a return
statement was executed. All tests were conducted on a 1.2 GHz Intel P3
workstation with a 64/66 PCI bus running Linux 2.6.2 with the new
network API (NAPI), using FFPF with FRP and circular buffers of 1000