Re: Libpcap reentrancy and PF_RING patch

[Gregor Maier <gregor () net in tum de>]

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. another thread might use this timestamp) the loss of
> precision would be minimal. In general for high-performance packet
> handling, two system calls for reading one packet are too many and this
> is yet another reason why pcap on linux could be optimized. What do you
> think?

I see a problem if the timestamps of two packets are exchanged, because
then it will appear as though the appeared in a different order! Loss in
precision is less of a problem but timestamp reordering *is* a problem.
IIRC the BPF expression is not evaluated between the call to read the
packet and the ioctl to retrieve the timestamp, since BPF filtering is
done in the kernel.


> > I think you won't be able to achieve reentrancy when reading from one
> > pcap handle without locking! Note however, that reading from different
> > pcap handles (e.g., one handle per thread) is already thread safe, since
> > no global data structures are used.
>
> Correct but pcap/Linux do not offer packet load sharing across pcap
> sockets (e.g. see socket clustering support into PF_RING) so opening
> simultaneously several sockets won't solve the problem either

I solved this by having one thread that just reads the packet off the
kernel, dispatches it to one of a number of worker threads and then
reads the next packet.
If this is too slow, your bottleneck is more likely in the kernel anyway.


cu
Gregor

Attachment: signature.asc
Description: OpenPGP digital signature