#10 PF_RING support

[spike]

Hi.
Pcapsipdump are single-flow process. If the code supported PF_RING, then it would be possible to use additional processor cores to perform the task.
About PF_RING: "PF_RING™ is a new type of network socket that dramatically improves the packet capture speed"
https://www.net.in.tum.de/fileadmin/bibtex/publications/theses/2014-gallenmueller-high-speed-packet-processing.pdf
http://luca.ntop.org/TMA_PhD_School_2011.pdf
http://www.ntop.org/products/packet-capture/pf_ring/

[spike]

Sorry, duplicates https://sourceforge.net/p/pcapsipdump/patches/4/
Please, cancel this ticket

[Aex Aey]

PF_RING kernel interface is not quite the same as PACKET_RX_RING support that [r43] introduced.

PF_RING is supposed to be faster (0-copy, whereas libcap 1.x is 1-copy, and libpcap 0.x is 2-copy). Although, it could be debatable if that makes all that much of a difference - on a modern high-end system, RAM (or local RAM on a NUMA system) would typically be plenty fast to accommodate few copies of 100Gbit/s line-speed stream. On the other hand, context switches between kernel and userspace do eat into performance rather hard. Same for a hypothetical situation where NIC/kernel is stuck on one NUMA cluster, while libpcap/pcapsipdump - on another, and that 1-copy happens across a relatively slow inter-socket link.

Either way, it's a delicate subject, and if I may suggest - if you still see high CPU spikes (after adding a generously-size "-B" buffer), have a look at "top" to see if that's "us" (user-space), "sy" (kernel) or "wa" (io-wait) that is actually peaking. Chances are - it's going to be user-space. In that event, go ahead and profile pcapsipdump (re-compile with "-pg" option, then run with "gprof" prefix and output redirect to a log file).