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:

  1. Available for Linux kernels 2.6.X.
  2. New As of version 4.X, PF_RING can be used with vanilla kernels (i.e. no kernel patch required).
  3. New PF_RING-aware drivers for increased packet capture acceleration.
  4. New User-space driver for DNA (Direct NIC Access) and extreme packet capture speed as the NIC NPU (Network Process Unit) is pushing packets to userland without any kernel intervention.
  5. Device driver independent (best results can be achieved using network cards that support NAPI such as the Intel cards)
  6. Kernel-based packet capture and sampling.
  7. Libpcap support (see below) for seamless integration with existing pcap-based applications.
  8. Ability to specify hundred of header filters in addition to BPF.
  9. Content inspection, so that only packets matching the payload filter are passed.
  10. PF_RING plugins for advanced packet parsing and content filtering.
  11. Ability to work in transparent mode (i.e. the packets are also forwarded to upperlinks so existing applications will work as usual).
  12. 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.

 

PF_RING Flavors

PF_RING is polling packets from NICs by means of Linux NAPI. This means that NAPI copies packets from the NIC to the PF_RING circular buffer, and then the userland application reads packets from ring. In this scenario, there are two pollers, both the application and NAPI and this results in CPU cycles used for this polling; the advantage is that PF_RING can distribute incoming packets to multiple rings (hence multiple applications) simultaneously.

PF_RING DNA (Direct NIC Access) is a way to map NIC memory and registers to userland so that packet copy from the NIC to the DMA ring is done by the NIC NPU (Network Process Unit) and not by NAPI. This results in better performance as CPU cycles are used uniquely for consuming packets and not for moving them off the adapter. The drawback is that only one application at time can open the DMA ring, or in other words that applications in userland need to talk each other in order to distribute packets.

In a nutshell if you like flexibility you should use PF_RING, if you want pure speed PF_RING DNA is the solution. Please note that in DNA mode NAPI polling does not take place, hence PF_RING features such as reflection and packet filtering are not supported.

 

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: