Re: Libpcap reentrancy and PF_RING patch

[Guy Harris <guy () alum mit edu>]

Luca Deri wrote:

> This function is the same as pcap_next with the difference that a buffer 
> + buffersize is added. This allows libpcap not to use the shared buffer 
> (e.g. allocated in pcap_open_xxx) so that replacing in applications 
> calls of pcap_next with calls to pcap_next_pkt adds reentrancy without 
> the need to use a mutex.

Presumably it's intentional that all the packets within a given buffer 
read from the capture device be processed in the same thread.

However, this means that p->cc is a shared variable - it shouldn't be, 
as it's the number of packets in the buffer being processed, and if 
there's no shared buffer, each buffer needs to have its own packet count 
value.  (Consider one thread processing all the packets in one buffer, 
and then another thread reading another group of packets into another 
buffer.)

Note also that, as per Paolo Abeni's mail - and his mmap patch - with 
memory-mapped access to packets, the callback routine is called with a 
pointer to the packet data in the memory-mapped buffer; how would that 
work with your scheme, and can it be made to work without extra copies?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.