Hello everyone.
Is it possible to implement DPC for the NDIS filter driver for both the send and receive paths?
I want to send data packets from both paths to another device (on the FTDI), and when DPC is called to read data from that device, complete the process of sending or receiving those data packets.
Thank You.
NDIS has NdisMQueueDpc, but I don’t see how that applies to your architecture. You say “when the DPC is called”, but who is going to call it?
I stated my question poorly, sorry. I think you want to redirect NDIS read and write packets from your filter into another NDIS driver. I’m just wondering if you have thought about the actual mechanism. How will your filter find the FTDI driver? It’s not hard to feed requests into another driver, if you can find it. I don’t know why a DPC would be involved, which is what prompted my poor question. You’d just send a blocking request and wait for the completion. Right?
Thank Yo Mr. Tim_Roberts.
As I said, I wrote filter driver, that captures uploading and downloading network traffic, sends
it to user via the IRP. User program does some changes on that payloads using USB device (FTDI-FPGA), and returns to drivers dispatch routine for furder sending (in place of FilterSendNetBufferLists and FilterReceiveNetBufferLists routines). Its working well, but now I want to use DPC in place of user program. So I must compleate both payloads inside that two (FilterSendNetBufferLists and FilterReceiveNetBufferLists) routines, write peyload to FTDI device, queue DPC object from inside that two ruotines (Can I queue DPC from inside FilterSendNetBufferLists and FilterReceiveNetBufferLists?). And all work, I was doing inside user program, now I must do inside DPC routine (read from FTDI device (asinchronows read) and send to miniport or protocol binding). In other words I want to change user program with DPC.
So my questions was: can I queue DPC object from filter driver? Becouse DPC object is related with device, but filter driver does't create device. If I can use device, created by minidriver (network card), how can I do it. From where to get input parameters: NdisInterruptHandle, MessageId, MiniportDpcContext of NdisMQueueDpc.
You say "How will your filter find the FTDI driver? ". I don't know yet, but I thing, I will use WinUSB driver, that expose wmi or to use documented IRPs to WinUSB driver (via the IRP_MJ_INTERNAL_DEVICE_CONTROL). Earlier FTDI was using her own undocumented FTDI driver, and we could not use it in kernel mode. Now FTDI use WinUSB, that is docdumented.
DPCs are not “related with device”. Almost nothing in WIndows is actually associated with a physical device. Things can be associated with a DEVICE_OBJECT, but even software drivers have those. Look at the definition of KeInitializeDpc – there is nothing device related there.
The DpcForIsr routine is associated with a hardware interrupt, but that’s just one specific kind of DPC.
There are no restrictions on calling NdisMQueueDpc.
I suspect you will find that it’s still easier to send this through a user-mode helper.
Well, if I have any questions, I'll ask them. Thank you.
Hello Mr.Tim_Roberts.
Can you only tell me whether I am right or not?
I want to queue custom DPC objects from inside FilterSendNetBufferLists and FilterReceiveNetBufferLists modules with the list of cloned NBLs ( KeInsertQueueDpc).
From inside CustomDpc module I want queue work items(ExQueueWorkItem()) to run in a system thread on PASSIVE_LEVEL, for every net buffer.
And inside that sistem threads use USB device (to do overlapped read and write operations to that device with peyloads from that NBLs). And finally send or receive all NBLs ( NdisFSendNetBufferLists or NdisFIndicateReceiveNetBufferLists) already modified NBLs.
You said " ....it’s still easier to send this through a user-mode helper". But I want to get rid of the user program and delegate all the work to the driver, without the need to run an additional component(user program).
The context switch from DPC to WorkItem thread is approximately the same performance cost as the context switch to user mode.
Why use a DPC for this, instead of just queueing the work items from the filter routines? I’m not saying I know the right answer, I’m just wondering what was your thinking.
Thank you, Mr. Mark_Roddy.
Mr. Tim Roberts. I don't know how to do this, so I'm asking you. My only goal is to get rid of the user program. I can't decide if I need to perform a read/write operation on a slow USB device, whether it's better to do it through a DPC, threaded DPC or a work item. I think DPCs also have a limited execution time, just like interrupt routines. Faster execution is also an important factor, since we're dealing with network packets.
I still don’t understand why you want to eliminate the user-mode helper. The cost of a context switch is insignificant when compared to the overhead involved in submitting a USB request and waiting for a response, which involves many hundreds of microseconds. Debugging and error handling are VASTLY easier in user mode. And remember, despite what some people seem to think, the CPU operates at exactly the same speed in user mode as it does in kernel mode.
Dear Mr. Tim Roberts, In the future, we plan to run our driver on a computer without a hard drive; the entire Windows operating system will reside in RAM. Our driver will be part of the Windows system, without any user programs.
Windows has to boot from a mass storage device of some kind. Maybe an SSD, maybe a PXE network source, but there must be a backing store. Drivers and DLLs are all mapped into memory from that backing store. MANY drivers, including in-the-box drivers, have user-mode helper apps or service apps.
Thanks, Mr.Tim_Roberts. I haven't gotten to that point yet. I just want to get rid of the user-mode helper, maybe for academic purposes. I just want to. I just don't know how to do. What approch to implement? In two words, please. Use DPC, a work item, or a system thread.
I've studied these methods, but I can't make a decision.
A DPC is not the right answer. Its environment is too restricted to call another driver. You could certainly use a work item (with FltQueueGenericWorkItem) or a system thread, assuming you can figure out how to get a kernel handle to the FTDI driver.
Well. Mr. Tim_Roberts. May be creating system thread is most convevenient way.
Perhaps, if that makes the most sense to you. There are still things to think about, however. You won’t want to spin off a new thread for every request, so I expect you’ll have one long-running thread. That means you’ll need some kind of “request queue” that the thread will listen to for things it should do. Your filter routines would push a request on that queue, and then (somehow) wait for a response.
That is exactly what FltQueueGenericWorkItem does, which might encourage you to lean more that way.
Yes, Mr. Tim Roberts. I'll have one system thread that will run as a user program and wait for an asynchronous read/write event each time. It will extract data from the nbl queue cloned by the filter drivers, send it to the WinUSB driver (FTDI driver), and wait for a response. Then, send the processed packets to the miniport or protocol.
Thank you, Mr. Tim Roberts.