Re: Creating a KMDF NDIS <==> USB driver

Tech-Archive recommends: Fix windows errors by optimizing your registry

chris.aseltine@xxxxxxxxx wrote:

I'm assuming that to utilize this approach, I'll scrap most of the
existing code in NICAllocRecvResources(), and instead simply set up a
continuous reader on the BULK IN endpoint -- and inside the completion
routine for the reader, just call NICIndicateReceivedPacket() for each
completed read. (Maxim, I'm operating under the assumption that each
completed read from the device contains a full ethernet frame.)

By the way, looking at the code inside NICIndicateReceivedPacket -- it
looks like they temporarily raise the IRQL to DISPATCH_LEVEL if
"Adapter->HardwareDevice" is TRUE -- yet, if I'm reading the KMDF help
file correctly, the continuous reader callback is already called at
DISPATCH_LEVEL -- so despite the bit about Adapter->HardwareDevice
being true in this case, I think I could just leave the IRQL
alone...right?

Is this done because the reads are posted from a work item, which is
running at PASSIVE_LEVEL?

Also, I don't suppose I can "scrap" most of the code in
NICAllocRecvSources, as it seems NDIS wants the frames stored in some
previously configured resources through NdisAllocateBuffer/Packet().
However, it does seem like I can at least avoid the complexity of
having a queue of these resources, and perhaps just create one of each
(packet, buffer, etc.) given that I am limited by the hardware in this
instance -- would you agree?

I'm thinking the same does not apply for the "send" side of the
equation -- I'll definitely need to be able to queue "write" frame
requests that are coming from the OS, and rather than just manipulate
some locking mechanism inside the "write" completion routine, it seems
like it might be wiser just to leave in place the queuing mechanism
that already exists in the driver -- agree?

-Chris

.