tcpdump mailing list archives
Re: Libpcap reentrancy and PF_RING patch
From: Luca Deri <deri () ntop org>
Date: Thu, 3 Jan 2008 01:29:28 +0100
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 isnecessary to perform a memcpy from the kernel buffer to the userprovided one, but this solution will remove the performance gain of thememory 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 NOTICEThis 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.
Current thread:
- Re: Libpcap reentrancy and PF_RING patch Guy Harris (Jan 01)
- Re: Libpcap reentrancy and PF_RING patch Luca Deri (Jan 02)
- <Possible follow-ups>
- Re: Libpcap reentrancy and PF_RING patch Paolo Abeni (Jan 02)
- Re: Libpcap reentrancy and PF_RING patch Luca Deri (Jan 02)
- Re: Libpcap reentrancy and PF_RING patch Paolo Abeni (Jan 03)
- Re: Libpcap reentrancy and PF_RING patch Luca Deri (Jan 02)
- Re: Libpcap reentrancy and PF_RING patch Luca Deri (Jan 02)
- Re: Libpcap reentrancy and PF_RING patch Gregor Maier (Jan 07)
- Re: Libpcap reentrancy and PF_RING patch Luca Deri (Jan 02)
- Re: Libpcap reentrancy and PF_RING patch Guy Harris (Jan 05)
- Re: Libpcap reentrancy and PF_RING patch Luca Deri (Jan 06)
- Re: Libpcap reentrancy and PF_RING patch Guy Harris (Jan 06)
- Re: Libpcap reentrancy and PF_RING patch Luca Deri (Jan 06)
- Re: Libpcap reentrancy and PF_RING patch Guy Harris (Jan 06)
- Re: Libpcap reentrancy and PF_RING patch Guy Harris (Jan 10)
- Re: Libpcap reentrancy and PF_RING patch Guy Harris (Jan 05)