On Sun, Dec 30, 2001 at 12:07:34AM -0500, Ashley Thomas wrote: > So therefore pcap_next gets one packet at a time from the buffer. > If the processing takes time when there is lot of packet coming to kernel > (or to NIC) > libpcap is not reading it from kernel unless these packets in the buffer > are processed completely .. am i right ?
Right. libpcap only refills the buffer, reading packets from the kernel, when you try to read from the buffer when it's emptied. > So does the packet drops occur at the kernel ? Yes, packet drops can occur in the kernel if the libpcap application isn't processing packets fast enough (regardless of whether the application uses "pcap_next()" or not). > How much capacity can kernel or NIC have usually (i know it is a vague > question but what is the figure usually) The buffering is in BPF; libpcap 0.6.2 tries to set it to 32Kbytes, and, if that fails with ENOBUFS (meaning "that buffer size is too big", not to be confused with "my spoon is too big") keeps dividing the size in half until it finds a size that works. > And all in all there is 2 Queues involved that a packet will see > ie at NIC and at libpcap. correct ? The two queues involved in a system with BPF are the NIC's ring buffer or equivalent, and the buffer in BPF. > Also for pcap_read() function, which implementation is taken > from pcap-bpf.c or pcap-BPF.c In all of the versions of libpcap I've seen, the implementation that's used is the one in "pcap-bpf.c", because, in all the versions of libpcap I've seen, there is no "pcap-BPF.c", hence there's no "pcap-BPF.c" implementation to use. Where have you seen a "pcap-BPF.c"? - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
