Re: Libpcap reentrancy and PF_RING patch

[Luca Deri <deri () ntop org>]

Paolo


> ===================================================================
> RCS file: /tcpdump/master/libpcap/pcap-usb-linux.c,v
> retrieving revision 1.20
> diff -r1.20 pcap-usb-linux.c
> 652c652
> < usb_read_linux_mmap(pcap_t *handle, int max_packets, pcap_handler  
> callback, u_char *user)
> ---
> > usb_read_linux_mmap(pcap_t *handle, int max_packets, pcap_handler  
> > callback, u_char *user, u_char *buf, u_short bufsize)
> 696c696
> <                    hdr = (pcap_usb_header*) &handle->buffer[vec[i]];
> ---
> >                         hdr = (pcap_usb_header*) &buf[vec[i]];

Thanks for the fix

> >
>
>
> Here handle->buffer refers to a memory mapped kernel buffer, which  
> holds
> the USB Request Blocks and related meta-data. To make the patch work  
> is
> necessary to perform a memcpy from the kernel buffer to the user
> provided one, but this solution will remove the performance gain of  
> the
> memory mapped access.

perhaps a spinlock will be enough?

In general the question is pretty simple. We have multicore CPUs and  
in order to exploit them we need to use threads. Putting a mutex  
around pcap is not a good idea as this has a major impact on  
performance because the lock around a pcap_xx call is too coarse- 
grained. The solution is to make libpcap reentrant either removing  
shared data-structures or adding mutexes (better spinlocks) into the  
library. As the library is mostly reentrant, I see a value of doing  
this effort into libpcap.

Regards, Luca



> ciao,
>
> Paolo
> --------------------------------------------------------------------
>
> CONFIDENTIALITY NOTICE
>
> This message and its attachments are addressed solely to the persons  
> above and may contain confidential information. If you have received  
> the message in error, be informed that any use of the content hereof  
> is prohibited. Please return it immediately to the sender and delete  
> the message. Should you have any questions, please contact us by  
> replying to webmaster () telecomitalia it.
>
>        Thank you
>
>                                        www.telecomitalia.it
>
> --------------------------------------------------------------------
>
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.