tcpdump mailing list archives
Re: Libpcap reentrancy and PF_RING patch
From: Luca Deri <deri () ntop org>
Date: Sun, 6 Jan 2008 12:32:38 +0100
Guyyour comments are very valuable: thanks. I have enclosed a new patch that should address all of them.
I have modified the configure so that the libpfring is included into libpcap.a. This means that apps that will be linked against libpcap- PF_RING won't also need to link against -lpfring.
I have made some tests with/without PF_RING/ring module and everything seems to work. basically an application linked against libpcap- PF_RING will take advantage of PF_RING if the ring module has been loaded, or fallback to default libpcap if the ring module is not loaded. This means that PF_RING should be transparent to users beside the speed advantage offered by PF_RING.
Other comments are inline.
Attachment:
pf_ring_patch.diff.gz
Description:
On Jan 6, 2008, at 11:17 AM, Guy Harris wrote:
Luca Deri wrote:Yes it will work correctly as when the PF_RING socket is open, the call will fail and the library will fall back to standard pcap....in which case it will1) do getsockopt(handle->fd, 0, PACKET_STATISTICS, &kstats, &len) on the PF_PACKET socket rather than doing getsockopt(handle->fd, SOL_SOCKET, PACKET_STATISTICS, &kstats, &len), as it would do if compiled without PF_RING supportand2) assume that the statistics are not reset after doing that call, rather than assuming that they *are* reset, as i would do if compiled without PF_RING support.
Fixed
Do the PF_RING patches change the behavior of PF_PACKET sockets, so that they support doing a PACKET_STATISTICS getsockopt() with a level of 0, and so that doing that is like doing a PACKET_STATISTICS getsockopt() with a level of SOL_SOCKET, except that PACKET_STATISTICS with a level of 0 doesn't reset the statistics?
PF_RING always returns absolute stats
If not, then that can't be done with an #ifdef - *both* code paths need to be supported at run time if PF_RING support is compiled in, with the code path selected based on whether the pcap_t uses a PF_RING socket or a PF_PACKET socket. (That can be done by having two separate routines, one for PF_RING sockets and one for PF_PACKET sockets, with handle->stats_op set to the appropriate routine, or by having one routine that, if PF_RING support is compiled in, checks whether handle->ring is null or not.)
Fixed
PF_RING is not ethernet only. I have changed the patch so that your comment is addressed.BTW, it appears to unconditionally set handle->linktype to DLT_EN10MB if PF_RING is being used. What if the device on which you're capturing is, for example, a PPP link, or an 802.11 device in monitor mode? Can you get 802.11 headers, or 802.11 headers plus a radio header, from an 802.11 device with PF_RING?
Also, what happens if pfring_open() is passed a null pointer, or the string "any", as an argument? Does it fail, or does it return a "pfring *" that supplies packets from all adapters? (The "Improving Passive Packet Capture: Beyond Device Polling" paper saysIf a PF_RING socket is bound to an adapted (via the bind() syscall), such adapter will be used in read-only mode until the socket is destroyed.Does that mean you can have a PF_RING socket not bound to an adapter and, if so, does that supply packets from all adapters?)
The paper is not updated with the current developments. PF_RING can be bond to any interface, including the 'any' device.
Regards, Luca
- 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, (continued)
- Re: Libpcap reentrancy and PF_RING patch Luca Deri (Jan 02)
- 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 Luca Deri (Jan 22)
- Re: Libpcap reentrancy and PF_RING patch Guy Harris (Jan 24)
- Re: Libpcap reentrancy and PF_RING patch Guy Harris (Jan 05)