Jim, I am not sure I can follow you 100%. All I say is that with PF_RING "vanilla" there is no zero-copy, we have to deal with the driver and the kernel and thus the performance is not line rate.
With DNA, the application accesses the packet directly in memory with no need to copy. As we do prefetching in DNA, basically you have the packet in memory ready to go. And this is the whole packet, not just the header. For instance we have developed a packet-to-disk application that captures and writes to disk a 10G stream with no loss. Writing entire packets to disk means that you stress a lot the memory (and the disk_ similar as switching packet across interfaces, again at line rate. So perhaps we can't offer you a free lunch, but zero-copy allows you to handle 10G for sure on a modern machine with a decent memory bandwidth (e.g. sandy bridge or better) Cheers Luca On Sep 14, 2012, at 7:17 PM, Jim Lloyd <[email protected]> wrote: > Can you please confirm my understanding of how memory bandwidth affects the > ability of PF_RING to do full packet capture at wire speeds? > > Assume we want to capture data from a saturated 10GigE link. That corresponds > to 10 billion bits/sec, or about 1.25 billion bytes/sec. > > Packets arrive in the NIC and must be copied to the ring buffer, so the > system will consume 1.25GBps of memory bandwidth, even if libzero is used. > Correct? Even with DMA, memory bandwidth is consumed. > > If the PF_RING enabled libpcap is used, there will be one extra copy per > packet to deliver packet to the userland application, requiring 2.5GBps of > memory bandwidth. Correct? > > If we ignore L1/L2/L3 caches, current servers will typically have more than > 2.5Gbps of memory bandwidth available, but in practice, actual bandwidth is > limited at about that amount. So, eliminating that extra packet copy is > indeed the difference between consuming about 50% of the memory bandwidth vs. > consuming about 100% of the memory bandwidth. But libzero won't drop the > memory bandwidth consumed by packet capture down to 0%. There is no free > lunch. > > Have I made any gross errors here? > > Thanks. > > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc _______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
