Burton Strauss wrote:
Near real-time scenario - suppose I need to process packets as quickly as
they arrive. The per-packet processing time can exceed the inter-arrival
time and so I want to create a bunch of worker threads to process packets
in parallel.
I.e., you're running on an MP machine, so that the per-packet processing
time averaged over all processors is < the inter-arrival time. (I
assume "can exceed" means "can exceed for a long enough time that
buffering doesn't fix the problem.)
(2) Internally within pcap_t there is NO serialization. pcap_t is an opaque
structure, but if you look at it in pcap_int.h, it's just a bunch of
counters, fields and pointers.
I.e., libpcap isn't thread-safe.
(2) The actual read operation is different for EACH environment, through the
read_op:
Yes, that's an intrinsic characteristic of libpcap, given that the
underlying OSes on which it runs provide very different mechanisms for
packet capture. (It was even an intrinsic characteristic before we did
the switching through the read_op member of pcap_t - it was done there
because there were different "pcap_read()" routines on different
platforms. The read_op member just lets us support different mechanisms
- e.g., regular capture and capture from DAG cards, or various types of
remote capture, or... - on the *same* platform.)
(4) General thread safety. In the mailing list - at least as of a year ago
- there were still some questions as to whether the DAG, DLPI (HP/Solaris)
versions were really thread safe.
http://www.tcpdump.org/lists/workers/2004/04/msg00179.html.
That thread started out with a question that appeared to ask about
capturing on multiple interfaces, with the capturing on each individual
interface being single-threaded:
http://www.tcpdump.org/lists/workers/2004/04/msg00174.html
"is pcap really thread-safe, especially under linux? Did anybody really
try to run it on multiple interfaces, one per thread?"
You're asking for something even *more* demanding, i.e. the ability to
run multiple threads on the *same* interface. libpcap offers no
guarantee of this.
You'd either have to modify libpcap to be thread-safe, or go with the
"manager thread" option, unless, on all the platforms you ever plan to
care about, you can show that the code is thread-safe without locks (but
note that the capture code path on any given platform is subject to
change in subsequent releases).
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.