Is it possible to retrieve the CPU that created a WDFREQUEST?

Question

I am trying to affinitise the completion of CompleteRequest to the CPU that originally issued the request. Is there a way to retrieve the CPU that issued the request during FdoDeviceControl or any onother way to see where the request came from before it entered the dispatch queue?

Purgation

Retrieving the CPU after that dispatch has happened is of course simple enough. But am I guaranteed that the callback function runs on the same core as the issues? – Purgation

Answer 1

Once you are in a DPC routine it's too late to tell where the request originated. You need to call KeGetCurrentProcessorNumberEx() before you queue the request to a DPC queue. I assume the request is an IRP...?

Yeorgi

David, I am using KMDF to handle request so the IRP is wrapped in a WDFREQUEST struct. At the point I see the request, it ha already passed through an I/O queue – Purgation

If you are using KMDF then you need to call WdfDeviceInitSetIoInCallerContextCallback(). This will allow you to peek at the I/O request before it gets place onto the kmdf I/O queue, you will be running in the process context of the I/O initiator and you will be on the core that initiated the I/O. From there you can call KeGetCurrentProcessorNumberEx() and save the result. – Yeorgi

Listed as an answer David, thanks. On a related note, am I guarateed that EvtDeviceWdmIrpPreprocess is also called in the context of the client (I am using guaranteed forward progress queues, so I need to make sure I ALWAYS get the call, which it looks like SetIoInCallerContextCallback doesnt do) – Purgation

That's unusual, I think you should always get the callback using WdfDeviceInitSetIoInCallerContextCallback(). Make sure you call it before calling WdfDeviceCreate(). In any case if there is a filter driver above you then, the original context may be lost. – Yeorgi