PF_RING
PF_RING is a new type of network socket that dramatically improves the packet capture speed, and that's characterized by the following properties:
- Available for Linux kernels 2.6.X.
- New As of version 4.X, PF_RING can be used with vanilla kernels (i.e. no kernel patch required).
- New PF_RING-aware drivers for increased packet capture acceleration.
- Device driver independent (best results can be achieved using network cards that support NAPI such as the Intel cards)
- Kernel-based packet capture and sampling.
- Libpcap support (see below) for seamless integration with existing pcap-based applications.
- Ability to specify hundred of header filters in addition to BPF.
- Content inspection, so that only packets matching the payload filter are passed.
- PF_RING plugins for advanced packet parsing and content filtering.
- Ability to work in transparent mode (i.e. the packets are also forwarded to upperlinks so existing applications will work as usual).
- New TNAPI support for wire-speed packet capture
If you want to know about PF_RING internals you have two options. Either read the papers:
or have a look at the source code.
Who needs PF_RING?
Basically everyone who has to handle many packets per second. The term 'many' changes according to the hardware you use for traffic analysis. It can range from 20k pkt/sec on a i486, to 500k pkt/sec on a Pentium IV. PF_RING not only enables you to capture packets faster, it also captures packets more efficiently preserving CPU cycles. Just to give you some figures you can see how fast nProbe, a NetFlow v5/v9 probe, can go using PF_RING, or have a look at the table below.
All tests have been performed using a Core2Duo 1.86 GHz, Ubuntu Server 9.10 (kernel 2.6.31-14), and an IXIA 400 traffic generator injecting traffic at wire rate (64 byte packets, 1.48 Mpps). As of PF_RING 4.1, when inserting the pf_ring module it is possible to specify three operational modes:
- 'insmod pf_ring.ko transparent_mode=0': standard NAPI polling
- 'insmod pf_ring.ko transparent_mode=1': PF_RING-aware driver copies the packets into PF_RING, while the same packet is still passed to TNAPI
- 'insmod pf_ring.ko transparent_mode=2': PF_RING-aware driver copies the packets into PF_RING, no the packet still is passed to TNAPI
Note that transparent_mode 1 and 2 are meaningless on non PF_RING-aware drivers. Inside the PF_RING/drivers/ directory you can find drivers for populat 1 and 10 Gbit network adapters. As you can read the code changes are very limited, so other drivers can be patched in a matter of minutes.
PF_RING-aware e1000e Driver Application transparent_mode=0 transparent_mode=1 transparent_mode=2 pfcount (with -a flag) 757 Kpps 795 Kpps 843 Kpps pfcount (without -a flag) 661 Kpps 700 Kpps 762 Kpps pcount (with PF_RING) 730 Kpps 763 Kpps 830 Kpps pcount (without PF_RING) 544 Kpps PF_RING-aware igb Driver - Single RX queue Application transparent_mode=0 transparent_mode=1 transparent_mode=2 pfcount (with -a flag) 650 Kpps 686 Kpps 761 Kpps pfcount (without -a flag) 586 Kpps 613 Kpps 672 Kpps pcount (with PF_RING) 613 Kpps 644 Kpps 711 Kpps pcount (without PF_RING) 544 Kpps PF_RING-aware igb Driver - 2 RX queues Application transparent_mode=0 transparent_mode=1 transparent_mode=2 pfcount (with -a flag) 600 Kpps 621 Kpps 673 Kpps pfcount (without -a flag) 534 Kpps 562 Kpps 609 Kpps pcount (with PF_RING) 566 Kpps 591 Kpps 654 Kpps pcount (without PF_RING) 544 Kpps PF_RING-aware igb Driver with TNAPI Application transparent_mode=0 transparent_mode=1 transparent_mode=2 pfcount (with -a flag) 261 Kpps 267 Kpps 269 Kpps pfcount (without -a flag) 1.13 Mpps 1.13 Mpps 1.46 Mpps pcount 1.48 Mpps NOTE
- pfcount is an application written on top of PF_RING, whereas pcount as been written on top of libcap-over-PF_RING. As applications are just counting packets with no extra processing, pfcount (with -a that means active packet polling) is sometimes slower of pcount that has to pay the libpcap overhead. This is justified by the fact that pfcount processes packets faster than pcount, hence it consumes all packets available quicker hence it calls the poll() (i.e. wait for incoming packets) more often. As poll() is rather costly, pcount performance is better than pfcount on this special case. In general applications have to do something with packets beside counting them, hence the performance of pure PF_RING-based applications should be better than pcap-based applications.
- For wire-rate packet capture even on a low-end Core2Duo TNAPI is the solution.
Download
PF_RING is available under the GPL licence and it can be downloaded from this page.
How to build and use PF_RING
- cd my_pf_ring_goes_here
- cd kernel
- make
- sudo insmod ./pf_ring.ko
- cd ../userland
- make
Read
Exploiting Commodity Multicore Systems for Network Traffic Analysis
for more information about PF_RING features.