1) I wouldn't expect any performance hit. I have code similar to that that handles millions of packets per second. A call to pcap_next_ex does not correspond to a transition user-kernel. Packets are received in user space in big buffers, so you might well have 1 syscall every hundreds (if not more) packets.
2) No. 3) The assumption is correctly. At those rates I would not expect any drop if you are using a decent NIC and you are fast enough at processing the packets. 4) It's definitely a supported configuration. The driver would use a different buffer per thread (and the buffer will contain only the filtered packets). Have a nice day GV From: [email protected] [mailto:[email protected]] On Behalf Of Monroe Comstock Sent: Friday, March 18, 2011 6:23 AM To: [email protected] Subject: [Winpcap-users] Followup question on Old Post Hi everyone, This is a follow up question to an old post (Dec of 2008). *BEGIN OLD POST* > On Wed, Dec 10, 2008 at 12:30 PM, Gianluca Varenni > <gianluca.varenni at > cacetech.com<https://www.winpcap.org/mailman/listinfo/winpcap-users>> wrote: >> >> ----- Original Message ----- From: "Victor Ginzburg" >> <vginzburg at >> gmail.com<https://www.winpcap.org/mailman/listinfo/winpcap-users>> >> To: <winpcap-users at >> winpcap.org<https://www.winpcap.org/mailman/listinfo/winpcap-users>> >> Sent: Monday, December 08, 2008 11:25 AM >> Subject: [Winpcap-users] pcap_next_ex >> >> >>> Hi All, >>> >>> Is there any way to pick-up multiple packets with one call rather than >>> one packet at a time with pcap_next_ex? >> >> No, at the moment there's no API for that. >> >>> And if yes, is there big >>> performance improvement in terms using less CPU? >> >> The performance improvement would be minimal. What is the packet rate >> that >> we are talking about? > > around 2000 per second At 2k packets per second forget about any performance improvement receiving multiple packets within one call. If you have any performance problems, they are definitely not due to the calls to pcap_next_ex returning one packet at a time. Have a nice day GV *END OLD POST* Question 1) I have an application that will need to retrieve 50k packets/second (all UDP, all ~200 bytes, coming from a range of ports, for which I will use a filter). Will using pcap_next_ex() in this case cause a performance hit? IE Does it have to transition to kernel mode for getting each packet? Or has it pulled a buffer from the kernel such that it's just reading the copied buffer until it is exhausted? Then subsequently reading the kernel buffer again? If it has to transition to kernel mode what is the cost for making 50000 transitions in per second? Question 2) Is there now or is there planned a way to read all the packets that are available in one call so that I can process all of them from a single call to pcap_next_ex() or some similar function? Question 3) If the answer to #2 is no, and the call to pcap_next_ex() only calls into the kernel periodically to retrieve the buffer and as long as my thread can keep up with processing the buffer, then I would assume that I would have no packet loss from the kernel buffer. Is this a correct assumption? Question 4) Is it possible/worthwhile to setup multiple threads to each have a filter that is a subset of the entire range of ports that need to be captured such that I can divvy up the work on a multiple core machine with each one calling pcap_next_ex() for its range of ports? Is the NPF driver designed to separate the packets into multiple kernel buffers and in turn farm them up to a user mode app? Would this be a benefit in performance? Thanks for the help! Monroe
_______________________________________________ Winpcap-users mailing list [email protected] https://www.winpcap.org/mailman/listinfo/winpcap-users
