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/
Recently I’ve discovered an issue using our NDIS6 protocol driver with Hyper-V network adapters. The issue is unique to this adapter and I don’t see the problem anywhere else. Our protocol driver has run on VMware, VirtualBox and numerous physical adapters without an issue. I’m hoping someone here will have some insight. I’ll try to put this in a nut shell and expand later.
To send network packets, the user creates the packet in user space and passes the typedef structure to the driver via ioctl call. From there we do the typical calls to:
Creating the NET_BUFFER_LIST is where it gets interesting.
Send Method 1:
I can use the MDL created from the locked user space memory with NdisAllocateNetBufferAndNetBufferList(), NdisSendNetBufferLists() then release the memory in the SendNetBufferListsCompleteHandler. This works fine with Hyper-V.
Send Method 2:
I can make a copy of the user space MDL with using NdisAllocateMemoryWithTagPriority(), NdisAllocateMdl(), release the user space memory and use the new MDL with NdisAllocateNetBufferAndNetBufferList() and NdisSendNetBufferLists(). This does not work with Hyper-V.
Why make a copy? The send performance can be significantly faster using kernel memory instead of user space memory (up to 20% faster). Perhaps someone knows more about this phenomenon since it’s counter intuitive. On some systems the copy makes no difference.
What happens when it does not work? It appears that the NET_BUFFER_LIST gets stuck (or lost) during the send and the SendNetBufferListsCompleteHandler is never called. I’m puzzled by this behavior. If I create a Hyper-V legacy adapter (emulated Intel 21140 PCI Fast Ethernet) it has no issues with method 2.
Even though I can solve the problem by using method 1 it’s just a work around solution. I don’t want to lose performance so I’ve added a patch that detects the Hyper-V adapter and disables method 2. Any suggestions? I can post the code that copies the MDL and NET_BUFFER_LIST if anyone is interested.
|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 January 2023||Live, Online|
|Developing Minifilters||20 March 2023||Live, Online|
|Writing WDF Drivers||TBD 2023||Live, Online|
|Internals & Software Drivers||17 April 2023||Live, Online|