[Winpcap-users] Best approach for multithreaded read/write

[J M]

Hello,
 
>From your experience, what is the best approach for a service using WinPcap to read/write raw packets at high speeds (Gbps or more).
 
I'm P/invoking from .NET.
 
For reading, I am currently using a single thread that invokes pcac_read_next_ex in a loop and copies the bytes (with Marshal.Copy) to a ring buffer. Another single thread converts those individual reads left in the ring buffer into TPL tasks to process the individual messages in managed thread pool threads, allowing multithreaded processing. I use a -1 timeout and switch to a wait on the result of pcap_getevent when a certain amount of consecutive reads don't yield a message. That way I limit CPU comsumption in that case.
 
For writing, I would like to be as multithreaded as possible, having into account that messages to be written are produced concurrently by multiple threads. If each thread can call pcap_sendpacket right away, and use the pinned buffer it already owns, I think the global performance must increase.
 
I'm aware that a single pcap_t contains certain resources that are not directly shareable by different threads (e.g., an errbuf). So I think I cannot reuse for writing the same pcap_t (from pcap_open) used for reading.
 
Furthermore, I think I cannot open a second pcap_t and use it for writing from several threads concurrently (for the same sharing problem).
 
One approach to do it would be to use Threading.ThreadLocal<T> in .NET. It gives a different instance of T per thread.
If I build a managed wrapper over pcap_t, initialized in every writing thread to the result of a new pcap_open (independent of the pcap_open for reading), and provide a destructor to conveniently recycle the pcap_t in case of thread destruction, I can have a convenient mechanism to have a different pcap_t per writing thread.
 
But what about global resources consumed by this approach? I plan to use thread pool threads to write (potencially a big number). How many resources does a pcap_t hold? Imagine multiplying it by 1000 or more.
 
Can an "only for writing" pcap_t be made tiny in resource consumption compared to a reading capable pcap_t or else will it also spend kernel buffers, capture all packets again even if no one will ask for them, etc.? I find prohibitive having 1001 pcap_t's, each consuming 1 MByte kernel buffer and capturing the whole stream of bytes from the NIC.
 
But, at the same time, synchronizing writes in my service to perform them with a single thread if the driver already perfoms that synchronization or it is avoidable is a wasteful expense of resources.
 
Thank you very much.
 
Regards,
J.M.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winpcap.org/pipermail/winpcap-users/attachments/20140214/919d0533/attachment.html>