As a rule of thumb, how much work can I do in an NDIS DPC interrupt?

Hey everyone,

I have an NDIS driver which uses scatter gather lists for DMA. Previously when my MiniportProcessSgList callback was invoked but I didn’t have room in my tx ring for the SGL, I’d fail the net buffer with NDIS_STATUS_RESOURCES and assume Windows would retry later.

This made NDISTest unhappy since it doesn’t want any failed net buffers. I switched this to stick the net buffer in a work queue, and when my NIC triggers my interrupt to complete pending net buffers freeing up space in the descriptor ring, I would pop net buffers off my work queue and insert them into my tx ring.

This works, but I was hoping some experts could weigh in on whether doing this amount of work in an interrupt is appropriate. Would I be better off queueing an NDIS work item from the interrupt to reschedule these pending net buffers? Is this something not worth worrying about?

I mainly ask because the literature I can find suggests that the main point of work items is to do things that must be done at PASSIVE while you’re at DISPATCH, and to process these net buffers I’d need to raise the IRQL to DISPATCH anyways, so maybe I’m approaching this problem from entirely the wrong angle.

Cheers,
David

The rule of thumb is that execution times of your DPC shouldn’t exceed 100 microseconds.

Not sure if this will work for your driver but some years ago they introduced Receive Side Scaling which does distributed processing and load balancing for network drivers.

https://docs.microsoft.com/en-us/windows-hardware/drivers/network/introduction-to-receive-side-scaling

//Daniel

Extending your device ringbuffer with a software overflow queue in your
driver that makes it ‘big enough’ is a pretty standard approach. I would
just keep doing that.

Mark Roddy