Re: Libpcap reentrancy and PF_RING patch

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

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. Maybe this is desired, but it
must nevertheless be clarified.
* Timestamps must not get reordered!
* Ideally pcap_loop() should also work.
* There should not be any race conditions.
* Luca's patch works around a shortcoming of pcap's userspace <-> kernel
interface. If reentrancy is really desired, then the place to implement
it is in the kernel, because:
        * The kernel already has serialized access to shared data structures
        * A deterministic load-balancing scheme can be implemented
          (round-robin, based on BPF-expressions, etc.)
        * It has better performance (which obviously is a major concern)
* Sometimes reentrancy means, that a mutex is required. Some parallel
code just cannot be implemented without using a mutex(1) (or higher
mechanism such as semaphores or monitors)
* It must be guaranteed, that the interface is indeed reentrant across
all operating systems and hardware backends. This will be hard.
* The pcap_next_pkt() function is nice and can get handy if one wants to
utilize multiple threads, but it does not provide reentrancy (due to the
problems mentioned in the other mails). So I would not call reentrant,
unless it really is.
* Note that implementing reentrancy and parallelism inside a library
will often mean that it cannot be implemented as efficient as when
implementing it in the application (due to a priori knowledge). IMHO
this is the case here. Doing reentrancy in libpcap will involve mutexes.
Doing it in the application might get around the mutexes, due to
application specific knowledge.


cu
Gregor

(1) please note, that for me a mutex is anything that guarantees
exclusive access, no matter which mechanism is used (i.e., whether a
spinlock is used or not).

Attachment: signature.asc
Description: OpenPGP digital signature