I am authoring my own tool written in Go (cgo) (using the gopacket package from Google), that captures packets and does some processing on them. I have made it possible to choose how the tool will capture packets: pcap (-lpcap), pf_ring (-lpfring), or af_packet (raw socket)
The results I'm getting, is that af_packet-mode has 0 packet loss, but the application needs to keep about 2 million packets in an internal buffer to keep up. Both pf_ring-mode and pcap-mode drops a lot of packets, probably about 30%, according to the stats reported by pcap_stats and pfring_stats. I am using a pf_ring-aware version of libpcap, and have installed the pf_ring drivers for my NIC, and the pf_ring instance shows up in /proc/net/pf_ring/<id>, which is also showing me the same drop numbers. Tweaks I have made so far is to increase the num_free_slots to 65536, but this made no notable difference. I also disabled Hyper-Threading in the BIOS, which was necessary to get the af_packet mode to not drop packets. I tested some of the included examples such as zcount (with option: -i eth5 -c 1) a pfcount, and they seemed to work fine, with 0 packet loss. One difference I'm noticing when comparing the numbers from pfcount with the numbers from my tool is that "Num Free Slots" shown in /proc/net/pf_ring/<id> sometimes drops to 0 in my tool. I have several tools that I want to run simultaneously, and so pf_ring (maybe with ZC) is probably what I want to end up with, but so far it's not working well. How can I troubleshoot this? - Lars
_______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
