Luca Deri wrote:
I have considered your suggestion to move pfring into a pcap-pfring.*
file.
I didn't make such a suggestion.
I did say
Would it work better if, for PF_RING sockets, there were a separate
pcap_read_pf_ring, and handle->read_op were set to pcap_read_pf_ring if
a PF_RING socke
Guy
I apologize for the late response.
I have considered your suggestion to move pfring into a pcap-pfring.*
file. I think that it's better to leave it into pcap-linux.c as moving
to a separate file would reduce the number of #ifdefs into pcap-
linux.c but this will require some pcap-linux.
On Jan 6, 2008, at 12:54 PM, Guy Harris wrote:
Would it work better if, for PF_RING sockets, there were a separate
pcap_read_pf_ring, and handle->read_op were set to pcap_read_pf_ring
if a PF_RING socket were being used? That'd avoid some per-packet
checks in the read_op routine, and migh
Hi,
IMHO if reentrancy support is desired for libpcap, then it must be done
properly. For me this means, that:
* the semantics must be clarified. I.e., if two threads read from the
same handle, then which thread gets which packet? Currently the packets
are distributed over the threads randomly.
Luca Deri wrote:
> that basically return the time of the day either of the packet when
> captured, or when ioctl is called.
>
> As libpcap is not calling this ioctl immediately (e.g. it might be that
> the BPF filter is evaluated), I suppose that even if the ioctl call is
> not in sync (e.g. anot
Luca Deri wrote:
your comments are very valuable: thanks. I have enclosed a new patch
that should address all of them.
It's still not a context or unified diff, and I've subsequently made
some changes to pcap-linux.c to move the SITA support code into
pcap-sita.c, so the patch didn't apply c
Guy
your 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 -lpfrin
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 will
1) do getsockopt(handle->fd, 0, PACKET_STATISTICS, &kstats, &len) on
the PF_PACKET socket rather than doing getsockopt
On Jan 5, 2008, at 11:52 PM, Guy Harris wrote:
Luca Deri wrote:
On Dec 31, 2007, at 10:21 PM, Guy Harris wrote:
You might want to split the PF_RING support and the reentrancy
changes into two patches.
I have enclosed the patch for PF_RING.
I've checked in Paolo Abeni's patch for memory-m
Luca Deri wrote:
On Dec 31, 2007, at 10:21 PM, Guy Harris wrote:
You might want to split the PF_RING support and the reentrancy changes
into two patches.
I have enclosed the patch for PF_RING.
I've checked in Paolo Abeni's patch for memory-mapped PF_PACKET access;
your patch isn't a contex
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 w
hello,
On Thu, 2008-01-03 at 01:29 +0100, Luca Deri wrote:
> > 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
> > p
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_rea
Guy
as I have explained in my previous reply, I don't think you're going
to use simultaneously pcap_loop and pcap_next_pkt, so I don't see a
problem here. However, this problem can be overcome by an if statement
like the one below
if(buf == handle->buffer) { <--- we use the s
Guy
pf_ring_patch.diff.gz
Description: GNU Zip compressed data
On Dec 31, 2007, at 10:21 PM, Guy Harris wrote:
Luca Deri wrote:
My patch also adds support for PF_RING (http://www.ntop.org/PF_RING.html
) that is a Linux packet acceleration technique that uses a shared
ring buffer betwe
Gregor,
many thanks for your comments. Please see my comments inline.
On Dec 31, 2007, at 3:59 PM, Gregor Maier wrote:
Hi Luca,
Hi all,
I'm afraid, but I think your patch has a race condition under (at
least
under Linux). In Linux two syscalls are required to read a packet.
First
you read
hello,
On Sun, 2007-12-30 at 12:09 +0100, Luca Deri wrote:
> please find enclosed a patch (against the code that's in CVS) that
> adds reentrancy in pcap.
There is an issue with the linux/usb code:
===
RCS file: /tcpdump/master/li
Guy Harris wrote:
Unless I'm misinterpreting socket(7), at least on Linux systems with the
SO_TIMESTAMP socket option, you can set that option and use recvmsg() to
read a packet; the control message for the packet will contain the time
stamp.
...although that doesn't address the issue of the
Gregor Maier wrote:
I'm afraid, but I think your patch has a race condition under (at least
under Linux). In Linux two syscalls are required to read a packet.
Unless I'm misinterpreting socket(7), at least on Linux systems with the
SO_TIMESTAMP socket option, you can set that option and use r
Luca Deri wrote:
My patch also adds support for PF_RING
(http://www.ntop.org/PF_RING.html) that is a Linux packet acceleration
technique that uses a shared ring buffer between the kernel and
user-space.
I seem to remember an earlier PF_RING paper that said that an interface
doing PF_RING c
Luca Deri wrote:
My patch also adds support for PF_RING
(http://www.ntop.org/PF_RING.html) that is a Linux packet acceleration
technique that uses a shared ring buffer between the kernel and
user-space. In addition to packet acceleration, it features also packet
filtering and classification.
Hi Luca,
Hi all,
I'm afraid, but I think your patch has a race condition under (at least
under Linux). In Linux two syscalls are required to read a packet. First
you read the packet, that you read the timestamp value with an ioctl. If
one thread gets scheduled just after the packet data is read, t
22 matches
Mail list logo
