PF_RING in 2012

Posted · Add Comment

From time to time the kernel folks are sick and tired of people saying PF_RING is better than what we have upstream, it really isn’t. Fortunately (for PF_RING) the story is a bit different not to mention that some of PF_RING features such as clustering have probably inspired AF_PACKET too.

For 2012 we have planned to make some enhancements to PF_RING and (we’ll be doing much more but this is just the next thing that will see the light) add one of the last missing features you can find on costly FPGA-based NICs. No, I am not talking about multi-10G packet capture/transmission speed, low latency, IDS/IPS acceleration, virtual machine support, or hardware packet filtering: all this is already part of PF_RING. What we are currently implementing is the ability to support TX and RX hardware timestamps as those offered by Intel 82580 NICs. Some of you might wonder why it’s so important. The answer is manyfold:

  • RX and TX timestamps are the recipe for computing one way delay.
  • The use of splitter or network partitions prevents receiving all packets from a single NIC. As network monitors might need to know which packet came first out of N interfaces, the only way of doing that is via packet timestamps that can enable us comparing packet arrival timestamps.
Synchronizing the time on a LAN is also challenging and we’re doing our best to make PF_RING a good friend of PTP so that in addition of saving money with costly GPS-based NICs you can use a single source of time at almost no cost. So PF_RING is not just packet capture, because packet capture (i.e. put a received raw packet onto a buffer) is just the first step for network monitoring/security and not the ultimate goal in life.

PS. We don’t like flames. We would have liked to merge PF_RING (or parts of it) with the vanilla kernel some years ago, but this idea was not liked by the kernel developers. We still hope that this will happen at some point.