Re: Libpcap on VMWare

[Michael Richardson <mcr () sandelman ca>]

> > > > > "Guy" == Guy Harris <guy () alum mit edu> writes:
    Guy> On Jan 12, 2010, at 7:05 PM, Dustin Spicuzza wrote:

    >> Yes, that was what I meant. We never tried -1. We're running
    >> single threaded with a select loop for pcap on two devices and
    >> some network communications, so we figured on the off chance that
    >> -1 would never return (which I'm sure it would), using a number
    >> would be easier.

    Guy> I could imagine that, on Linux with memory-mapped capture, if
    Guy> packets arrive fast enough, pcap_dispatch() could run forever;
    Guy> unless I'm missing something, the packet-processing loop in
    Guy> pcap_read_linux_mmap() could continue forever as long as
    Guy> pcap_get_ring_frame() always returns a new packet and nobody
    Guy> calls pcap_break_loop(), and if packets arrive fast enough
    Guy> that, after processing a packet, there is at least one more
    Guy> packet in the ring buffer, pcap_get_ring_frame() could always
    Guy> return a new packet.- 

This seems like a feature --- packets get transferred to userland with
no system calls.  If userland can not keep up, then what else can one
do?

If you coded a select() loop, and you did not randomize which source to
check first, and if you process all packets from one source before other
sources, if the first source was always ready, then the second source
would never get checked.

Of course, if you code a select() loop, then you can round robin if you
need to.

I think that maybe pcap_read_linux_mmap() might be a max_work argument
then?  
Or perhaps the interface needs to be able to deal with multiple sources
of packets?
  
-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr () sandelman ottawa on ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
                       then sign the petition. 
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.