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
signature.asc
Description: OpenPGP digital signature
