TNAPI

PF_RING

Exploiting Hardware Filtering in PF_RING-aware apps, Snort…

Introduction PF_RING filters have been designed to be efficient and versatile. PF_RING-based applications can use them for both reducing the amount of packets they need to process, and passing incoming packets to kernel plugins for further processing. Years ago, hardware packet filtering was limited to costly FPGA-based NICs, whereas today it is available also on commodity adapters such as Silicom 1/10 Gbit Director card, and Intel 82599-based 10 Gbit network adapters.   Filtering in PF_RING 5.2 Although past PF_RING versions supported limited hardware filtering, in PF_RING 5.2 we have completely …
PF_RING

Released PF_RING 5.1 and TNAPIv2

PF_RING 5.1 is a maintenance release that addresses some issues we identified in 5.0 that we released early this month. We have listen to your comments and tried to improve our software applications both in terms of stability and speed. In this release we introduce (PF_RING 5.0 was lacking TNAPI as we were busy coding this new TNAPIv2) a new version of TNAPI (v2) that has been completely rewritten based on the lessons learnt with DNA. The performance improvement with respect to v1 has been major. Just to give you …
Announce

PF_RING 5.0 Introduced: DNA 1/10 Gbit and vPF_RING

We’ve just cut the code of PF_RING 5.0. As it contains many changes with respect to the previous version, it deserved a major version number. We refreshed our DNA drivers to 1 Gbit Intel NICs (e1000e and igb families) in addition to the existing 10 Gbit DNA driver. All the DNA drivers source code is stored inside the PF_RING SVN. You can just install the DNA driver, and use our test applications (pfcount for receiving packets, and pfsend for generating/reproducing traffic) for enjoying 1/10 Gbit RX/TX wire-speed using commodity adapters. …
PF_RING

Packet Capture Performance at 10 Gbit: PF_RING vs TNAPI

Many of you are using PF_RING and TNAPI for accelerating packet capture performance, but have probably not tested the code for a while. In the past month we have tuned PF_RING performance and squeezed some extra packets captured implementing the quick_mode in PF_RING. When you do insmod pf_ring.ko quick_mode=1, PF_RING optimizes its operations for multi-queue RX adapters and applications capturing traffic from several RX queues simultaneously. The idea behind quick_mode is that people should use it whenever they are interested just in maximum packet capture performance, and do not need …
PF_RING

ntop and Silicom Inc join the forces

Since a few months ntop and Silicom have started to work together on various network-related topics. The idea is to enhance PF_RING and  TNAPI in order to offer better products and support for both the community and Silicom customers. Furthermore, Silicom produces very advanced products such as the content director card and the packet processor card, that could solve various network-related tasks including: packet mirroring, tapping, duplication packet steering QoS enforcement packet traffic analysis As these activities are performed in hardware, they operate at wire-speed (at both 1 and 10 …
PF_RING

10 Gbit Hardware Packet Filtering Using Commodity Network Adapters

The promise of filtering packets in hardware is not new. Unfortunately filtering network adapters are pretty expensive, not to mention if they run at 10 Gbit. Furthermore many commercial FPGA-based NICs feature hardware packet filtering, but often require card reconfiguration whenever flow rules are added/removed and have a limited set of rules that can be configured. The release of Intel X520, the first NIC based on the 82599-controller, has triggered my interest as this controller is much more powerful than what Linux can do with it. Thanks to support from …
PF_RING

10 Gbit PF_RING-based Hardware Packet Filtering and Balancing Previewed at the Intel Europe Conference

Intel Research Europe Conference, Bruxelles, May 4th 2010 Luca Deri and Joseph Gasparakis, senior Intel engineer, have previewed a new PF_RING-based technology they have co-developed that allows Linux users to fully exploit the hardware capabilities of the newest Intel X520 10 Gbit adapter (based on Intel 82599 controller). This technology that is close to public availability (at no cost), will enable PF_RING users to program the X520 card with (over 32’000) rules that allow to both balance and filter traffic in hardware with no CPU intervention. Linux users will be …
PF_RING

PF_RING and Transparent Mode

PF_RING has been designed for enhancing packet capture performance. This means that the RX path must be accelerated, and in particular a way to accelerate this is by reducing the journey of the packet from the adapter to userland. This is obtained by allowing the driver to push the packet from the NIC to PF_RING directly and not through the usual kernel path. For this reason PF_RING has introduced an option named “transparent mode” whose goal is to tune how packets are moved from the NIC to PF_RING. This option …
PF_RING

Exploiting Commodity Multi-core Systems for Network Traffic Analysis

This article Improvement of libpcap for lossless packet capturing in Linux using PF_RING kernel patch positions PF_RING (3.x, so some changes are needed when using version 4) against the Linux standard PF_PACKET packet capture facility. In PF_RING v4, due to popular demand, I have decided to move some of the PF_RING accelerations into the NIC driver with the advantage of being now able to compile PF_RING against an unpatched kernel. The PF_RING distribution has now a drivers/ directory that contains accelerated drivers for popular 1 and 10 Gbit adapter. This …
nProbe

Port Mirror vs Network Tap

In order to analyze network traffic, it’s necessary to feed ntop/nProbe with network packets. There are two solutions to the problem: port mirror (also called SPAN in Cisco parlance) network tap Prior to explain the differences between these two solutions, it’s important to understand how ethernet works. In 100 Mbit and above, hosts usually speak in full duplex meaning that a hosts can both send and receive simultaneously. This means that on a 100 Mbit cable connected to a host, the total amount of traffic that a host can send/receive is …
PF_RING

IRQ Balancing

On Linux, interrupts are handled automatically by the kernel. In particular there's a process named irqbalancer that is responsible for balancing interrupts across processors. Unfortunately the default is to let all processors handle interrupts with the result that the overall performance is not optimal in particular on multi-core systems. This is because modern NICs can have multiple RX queues that work perfectly if cache coherency is respected. This means that interrupts for ethX-RX queue Y must be sent to 1 (one) core or at most to a core and its Hyper-Threaded (HT) companion. If multiple processors handle the same RX queue, this invalidates the cache and performance gets worse. For this reason IRQ balancing is the key for performance. In particular what I suggest is to have 1/2 (in case of HT) core(s) handle the same interrupt. For this reason on Linux interrupts are usually send to all processors hence /prox/irq/X/smp_affinity is set to ffffffff that means all processors. Instead as I have just stated above it's better to avoid that all processors handle all interrupts. Example Read more