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.

Reply via email to