I’ve been continuing to experiment with WinpkFilter in C++ and I was wondering if there’s any way to detect traffic that might have been missed (with the adapter in listen mode) if the driver’s queue was to be full, e.g. if I can register an event to be notified if this situation occurs.
I also wanted to double-check one thing regarding the internal driver queue size, from what I found in some other thread ( https://www.ntkernel.com/forums/topic/jumbo-frame-9000-bytes-length-frames/#post-9330 ) the driver has 1000 buffers for 1514-byte sized packets. Does this mean that the queue will only ever store 1000 packets of size up to 1514 bytes or is the number of packets in the queue variable depending on their size?
The standard driver builds for Windows Vista and later pre-allocate (for performance reasons) 2048 packets of 1514 bytes each (9014 bytes for a jumbo-frame-enabled build). And this is the upper limit for the packet queue. There is no special event to signal when the queue limit has been reached, but if you are reading packets from the driver, providing 2048 INTERMEDIATE_BUFFERS, and getting all the 2048 packets returned, there is a good chance that some packets have passed by in listening mode.
It is not a big problem to increase the internal driver packet pool and/or add an extra event (note that signaling an event comes at a cost) in a custom build of the driver. However, if you need to capture vast amounts of data from a high-speed network, you might want to consider using the experimental Fast I/O API instead. It allows up to 16 shared memory sections to be allocated to deliver packets from the kernel to user space instead of using the driver’s internal packet queue and the ReadPacket API.