Author: Alfredo Cardigliano

Last week I have met some PF_RING ZC and DPDK users. The idea was to ask questions on PF_RING (for the existing ZC users) and understand (for DPDK users) whether it was a good idea to jump on ZC for future projects or stay on DPDK. The usual question people ask is: can you position ZC vs DPDK? The answer is not a simple yes/no. Let’s start from the beginning. When PF_RING was created, we have envisioned an API, persistent across network adapters, able to give people the ability to …

Modern network adapters such as Exablaze, Napatech and Silicom’s Intel FM10K, support hardware filters. Unfortunately every company has its own way to set filters, no unified API, and no support of any BPF-like filters. Most of the network monitoring community instead is used to set filters using BPF and thus powerful hardware filtering is present but unused. This has been the driving force for developing nBPF (ntop BPF). We have realized that most of the times filters include IP, port and protocol, that are exactly the features that hardware-based filters …

This is to announce the release of PF_RING 6.4 that contains various improvements, new network adapters supported in ZC mode (including Intel 100 Gbit), and bug fixes. Developers can access the documentation for the PF_RING 6.4 API in Doxygen format. Changelog PF_RING Library Improved Myricom support, new naming scheme to improve usability Improved Napatech support, 100G support Improved Accolade support New Invea-Tech support New API pfring_get_metadata to read ZC metadata New pfring_get_interface_speed API New API pfring_version_noring() C++ wrapper improvements Removed DNA legacy ZC Library New API pfring_zc_set_device_proc_stats to write /proc stats …

This is to announce the release of PF_RING 6.2 that has several improvements with respect to the previous version. As previously accounted, we have extended support of non-Intel devices in PF_RING to provide you the best experience supporting many new devices (and a few more will come in the following months). We have specialised PF_RING for FPGA-based adapters, and added support of 100 Gbit adapter such as those manufactured by Accolade technology and Napatech. As you might have noticed, we have moved release versioning to odd/even numbers. An even minor version …

In the past few years we have tried to open PF_RING in an attempt to turn it into the “new pcap” API for packet processing. Recently we have added native support for speedy FPGA-based NICs and thus created a single API for efficient NIC-independent packet processing. If you are interested in hearing more about this subject, you can have a look at the slides or watch the video of our presentation, held in Barcelona at the Suricata Conference 2015. Enjoy! …

For years we have optimised PF_RING to support multi-10 Gbit/40 Gbit operations in zero-copy at line rate using ZC. Our users know that using PF_RING they can operate at line rate in RX+TX, balance packets across processes, drop/prioritise traffic etc etc. After a few years where commodity NICs (mostly Intel) combined with PF_RING  have reached basically the same performance of FPGA-based adapters, the rush towards 100 Gbit has revamped interested towards non-commodity NICs. Due to this, you can now find on the market FPGA-based network adapters from companies such as …

Today we have released PF_RING 6.0.3,  a maintenance release that includes many fixes and small changes. The release changelog is listed below. PF_RING Library New pfring_open() flag PF_RING_USERSPACE_BPF to force userspace BPF instead of in-kernel BPF with standard drivers New API pfring_get_card_settings() to read max packet length and NIC rx/tx ring size New Napatech support Support for up to 64 channels with standard drivers, pfring_set_channel_mask() has a 64bit channel mask parameter now Reworked IPv6 parsing Configure parameter –disable-numa to remove libnuma dependency ARM fixes Minor bpf memory leak fix ZC …