For those familiar with DNA and Libzero, the main differences of ZC with respect to them are:
- We have unified the drivers for both in-kernel (former PF_RING-aware drivers) and kernel-bypass (former DNA) drivers. Now you can open the same device as “-i eth0” (in-kernel processing) and as “-i zc:eth0” (kernel bypass). In essence you decide at runtime what operating mode you want to use.
- All drivers memory is mapped in huge-pages for better performance.
- All operations are performed in zero-copy if you open the device as “zc:ethX”. You see that very easily doing this simple test (eth3 is a 10 Gbit interface running the PF_RING-aware ixgbe driver). The first command is able to send 0.82 Gbit, the second 10 Gbit.
- # ./zsend -i eth3 -c 3 -g 0
- # ./zsend -i zc:eth3 -c 3 -g 0
- ZC is KVM friendly, meaning that you can send/receive packets from applications and threads running on a VM (Virtual Machine) at 10 Gbit line rate, without using techniques such as PCIe passthrough. Note that the same application can run unchanged, both in the VM and the physical host: we’re really VM friendly with ZC.
- Similar to other network frameworks such as the Click Modular Router, we offer simple components such as queue, pool, worker, for creating applications in a few lines of code.
- The API has been simplified and rewritten. For instance with as low as 6 lines of code you can create a traffic aggregator and balancer (see examples).
- When operating in kernel-bypass, we allow you to interact with the IP stack and send packets from/to it. This will ease development of applications that need to operate at line rate but that sometimes need to interact with the host IP stack.
- We can operate in one-copy-mode when interacting with low-speed devices (e.g. WiFi adapters) or for allowing NICs for which we do not offer accelerate drivers for, to benefit of the ZC too: there is just one copy when the packet enters ZC, and nothing else.
- For no-for-profit people and research, we offer our products free of charge. For commercial customers, we have simplified the licensing model, so that there is just one license (and not two as before, one for DNA and one for Libzero, so in essence you now pay a lower license fee)
- We want this technology to be pervasive, so you need a license only for accelerated drivers, whereas for all the rest (e.g. KVM and one-copy support) you can use it for free with no license needed.
If you want to test PF_RING ZC, the best you can do is to read this quick start guide to be productive in a matter of minutes.
Q. What is the PF_RING ZC performance?
A. Line rate, any packet size, multi 10 Gbit. Just try it yourself using apps such as zcount and zsend.
Q. Will you still support DNA and Libzero?
A. For the time being we will continue to support DNA/Libzero although the future is PF_RING ZC as it offers several new features and a consistent API.
Q. Does PF_RING ZC support legacy applications such as those based on libpcap?
A. Yes, similar to its predecessor DNA, we support pcap-based applications as well other apps such as Snort via PF_RING DAQ.
Q. How do I open a queue from PF_RING ZC/libpcap?
A. You can use the syntax “zc:<clusterId>@<queueId>”. Example: pcount -i zc:4@0
Q. What adapters feature native ZC drivers?
A. We currently support Intel adapters (1 and 10 Gbit) in zero-copy mode, and all other adapters in 1-copy mode. Remember that as soon as the packets have been moved to the ZC world, you can pass them in zero-copy to an arbitrary number of applications, threads and VMs. In essence you pay the copy ticket just at the entrance.
Q. How do you position ZC with respect to other technologies such as DPDK?
A. DPDK is designed for developers who are designing applications close to the hardware, who know in detail the X86 architecture, who are willing to call network interfaces with hex PCI ID (eg. 0d:01.0). With PF_RING ZC, devices are called with their name (e.g. eth1), PF_RING ZC manages all the low-level details, as you can run you existing pcap-based apps with no headaches. ZC is a developer-friendly technology.