The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
When reading https://docs.microsoft.com/en-us/windows-hardware/drivers/network/pausing-a-filter-module and https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ndis/nc-ndis-filter_pause, I tend to think that the only way to fulfill some of the requirements is incrementing a shared counter for each NBL passed in calls to NdisFSendNetBufferLists or NdisFIndicateReceiveNetBufferLists from my filter driver and decrementing it for each NBL received back in calls to FilterSendNetBufferListsComplete or FilterReturnNetBufferLists (my handlers) from underlying or overlying drivers. Only when the count is zero can the pausing process be completed (with additional measures to make the check safe and prevent race conditions).
As even interlocked operations aren't free and every sharing should be avoided (my driver needs to cope with 10 Gbps traffic), I want to be sure I've understood the documentation correctly.
Can the algorithm be improved? I'm not only referring to more lightweight ways of performing the counting, that I'm already considering, like having a counter per processor and things like that.
Specifically, when the documentation says "Should not originate any new receive indications", "Should not originate any new send requests", is it referring to any calls to NdisFIndicateReceiveNetBufferLists or NdisFSendNetBufferLists from the filter driver? Or only to receive indications and send requests for new packets created genuinely by the filter driver, not those calls resulting from the driver altering/forwarding packets handed out by underlying or overlying drivers? Are all premature pause completion confirmations from the filter driver problematic?
For example, this phrase seems to relax receive rules a bit:
In the Pausing or Paused states, a filter driver should continue to handle OID requests or status indications. The driver should reject calls to its FilterSendNetBufferLists function. The driver can pass on calls to its FilterReceiveNetBufferLists function. However, the driver cannot pass any buffers that it created. The driver must not originate any receive indications or send requests.
It seems to point out that the deeper constraint is not being able to create buffers (allocate) after the filter driver confirms the pause; i.e., extending packets passing through the driver. But not all calls to NdisFIndicateReceiveNetBufferLists seem to be prohibited in paused mode, and there's still a hope that not all NBLs must be counted.
I'll appreciate any information that allows me to better assess/alleviate the need for NBL counting to properly implementing filter driver pausing.
Thank you very much.
|Upcoming OSR Seminars|
|OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!||Kernel Debugging||30 Mar 2020||OSR Seminar Space|
|Developing Minifilters||15 Jun 2020||LIVE ONLINE|
|Writing WDF Drivers||22 June 2020||LIVE ONLINE|
|Internals & Software Drivers||28 Sept 2020||Dulles, VA|