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.
_______________________________________________
Winpcap-users mailing list
[email protected]
https://www.winpcap.org/mailman/listinfo/winpcap-users
