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 Accolade Technology, CSPI/Myricom, and Napatech. If you want to adopt them in your apps, you need to modify the application code, learn a new API, recode some components. If you want to move to another adapter, you have to start-over and do it again.
In order to avoid this, we have decided to give our PF_RING users the best experience by extending PF_RING to natively support FPGA-based adapters. This means that you can take your existing PF_RING-based application or popular applications such as nProbe/n2disk, Wireshark, Suricata, Snort, Bro, Argus, and instead of waiting until somebody modifies their code, just run them on top of your favourite NIC. The only thing you have to care about is the device name, all the rest is the same. The names for network interfaces change according to the NIC manufacturer. Below you can read how to start nProbe (our PF_RING based NetFlow probe) when using some adapters we support:
- Accolade Technology: nprobe -i anic:1 (see README)
- CSPI/Myricom: nprobe -i myri:1 (see README)
- Napatech: nprobe -i nt:1 (see README)
- Intel: nprobe -i zc:eth1 (see README)
- Other adapters: nprobe -i eth1
Now you might wonder what are the differences between these adapters, and what are their costs. Well ntop is a software company and a vendor-neutral organisation whose goal is to serve our user community, not hardware vendors. We do not want to endorse product A or product B, but instead offer you the best experience. Our message is simple: if you develop your application on top of PF_RING or if you want to use popular open-source applications your investment will be preserved when moving from adapter A to adapter B. This is because PF_RING shields you from the underlying hardware as it will transparently take care of underlying hardware differences. For instance each network manufacturer who supports hardware timestamps has its own format. Instead of getting crazy supporting all of them in your application, PF_RING does it for you and gives you one single time format regardless of the network adapter.
Bottom line. Choose the adapter you like according to the features you need, and the budget you can allocate. PF_RING will support it. If you want to develop on cheap commodity adapters and then deploy your application at 100Gbit you can do that without changing a single line of code, but just changing the device name. We believe that this is a unique PF_RING feature: let end-users choose what NIC they like most for a project without being locked by a single vendor.
If you have the chance to come to the upcoming OISF 2015 Suricata conference, you can attend our speech about PF_RING. We would be glad to explain all this in detail. Hope to see you in Barcelona next month!
PS. if other network manufacturers would like their NIC be supported in PF_RING, of course they can contact us.