I have question regarding driver to driver communication.
I have to design a Kernal mode miniport driver which has to communicate
with another driver for sending/receiving data using IOCTL.
What I understood basically is that for data exchange I have to use
these calls for asynchronous operation.
IoBuildAsynchronousFsdRequest
IoCallDriver
My miniport driver does not have any thread i,e it is a passive
component.
The upper layer call the send data callback routine and we make IOCTL
call.
I am a bit confused with handling of data read operation. Is there a
way by which I can get interrupts
when the data is available by lower layer driver. The constraint is
that I can only use IOCTL.
Is there a way by which I can avoid creating a dedicated thread for
reading data from lower layer driver?
You don’t HAVE to use an IOCTL protocol. You could create a device interface and your own communication protocol that allows direct communication between two, or multiple drivers. Driver interfaces are well documented and are used in the Toaster example.
I have question regarding driver to driver communication.
I have to design a Kernal mode miniport driver which has to communicate with another driver for sending/receiving data using IOCTL.
What I understood basically is that for data exchange I have to use these calls for asynchronous operation.
IoBuildAsynchronousFsdRequest
IoCallDriver
My miniport driver does not have any thread i,e it is a passive component.
The upper layer call the send data callback routine and we make IOCTL call.
I am a bit confused with handling of data read operation. Is there a way by which I can get interrupts
when the data is available by lower layer driver. The constraint is that I can only use IOCTL.
Is there a way by which I can avoid creating a dedicated thread for reading data from lower layer driver?
I have question regarding driver to driver communication.
I have to design a Kernal mode miniport driver which has to communicate
with another driver for sending/receiving data using IOCTL.
…
The upper layer call the send data callback routine and we make IOCTL
call.
I am a bit confused with handling of data read operation. Is there a
way by which I can get interrupts
when the data is available by lower layer driver. The constraint is
that I can only use IOCTL.
You submit the ioctl, and have the lower driver holds on to it. When
the data comes in, the lower driver completes the ioctl and you get the
completion. Isn’t that what you’re after?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I would use IoAllocateIrp + IoCallDriver instead of IoBuildXxxx. This way you are not building a threaded irp and you can just let the thread which is sending the irp return up the stack and then use the completion routine in the irp to process the data when it completes
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@aol.in
Sent: Wednesday, October 26, 2011 12:33 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] driver to driver communication
Let’s say I have no other option other than using IOCTL. I will get the lower layer driver from some one else.
“You submit the ioctl, and have the lower driver holds on to it. When the data comes in, the lower driver completes the ioctl and you get the completion. Isn’t that what you’re after?”
Here @Tim Robers you mean to say that we should send an IRP_MJ_READ and then wait for the Iocomplete callback routine to be called and once the routine is called you send the another IRP_MJ_READ and continue this infinitely till the driver is closed. In the callback routine we should buffer and indicate the NDIS of the data availability so that it can read the data received.
Is this solution full proof. I mean is there any drawback of this ?.
One more query if we send a IRP_MJ_READ IRP followed by IRP_MJ_WRITE will these calls be queued in the destination driver ? will the IRP_MJ_WRITE be performed even if there is no data to be read and process IRP_MJ_READ.
“You submit the ioctl, and have the lower driver holds on to it. When the data comes in, the lower driver completes the ioctl and you get the completion. Isn’t that what you’re after?”
Here @Tim Robers you mean to say that we should send an IRP_MJ_READ and then wait for the Iocomplete callback routine to be called and once the routine is called you send the another IRP_MJ_READ and continue this infinitely till the driver is closed. In the callback routine we should buffer and indicate the NDIS of the data availability so that it can read the data received.
Yes.
Is this solution full proof. I mean is there any drawback of this ?.
You mean “foolproof”. This is the recommended method of dealing with
continuous streams like this. The only issue to consider is what
happens if the driver gets data while you are processing, in between the
completion and the next submission. If you have buffering in the
driver, that’s fine. If not, then you need to submit two read requests,
so there is still one waiting while you process the first.
One more query if we send a IRP_MJ_READ IRP followed by IRP_MJ_WRITE will these calls be queued in the destination driver ? will the IRP_MJ_WRITE be performed even if there is no data to be read and process IRP_MJ_READ.
That’s up to the driver The system doesn’t know about any relationship
between read and write requests. You have to design the driver to do
what makes sense.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Having done this for NDIS monitoring with Rawether for Windows
(http://rawether.net/) since as far back as NT 4 and Windows 95 I can give
the following advice:
1.) One can attempt to keep up with received by posting a LARGE number of
concurrent asynchronous reads (say 500 or so…). Have the driver queue them
all. Fill them with received packet data as it is received.
2.) The approach of 1.) really isn’t good enough on 1Gbps networks. The
bottleneck is is the number of kernel-to-user transitions. You will loose
some packets using 1.). Must reduce kernel-to-user transitions.
3.) Next step is to design read operation so that each read fetches a LARGE
number of packets in a SINGLE read operation. Here you must add structure
to your read buffer to identify where each packet’s data resides in the
large buffer. Once again having multiple concurrent asynchronous read
operations using large buffers is required (say 4 to 8 large buffer reads).
In addition, you must add an idle timeout so that large buffers are
completed SOMETIME even when there is very little traffic.
4.) Buffering packets in the driver may seem worthwhile, however you will
come to realize that no amount of buffering in the driver is sufficient (or
even helpful) when there is a runt packet flood. Better just to drop a
received packet if there is no pending read IRP to be filled.
5.) No matter what you try… you will loose some packets.
FWIW.
Good luck!
Thomas F. Divine
From: “Tim Roberts” Sent: Monday, October 31, 2011 3:23 PM To: “Windows System Software Devs Interest List” Subject: Re: [ntdev] driver to driver communication
> xxxxx@aol.in wrote: >> “You submit the ioctl, and have the lower driver holds on to it. When the >> data comes in, the lower driver completes the ioctl and you get the >> completion. Isn’t that what you’re after?” >> >> Here @Tim Robers you mean to say that we should send an IRP_MJ_READ and >> then wait for the Iocomplete callback routine to be called and once the >> routine is called you send the another IRP_MJ_READ and continue this >> infinitely till the driver is closed. In the callback routine we should >> buffer and indicate the NDIS of the data availability so that it can read >> the data received. > > Yes. > >> Is this solution full proof. I mean is there any drawback of this ?. > > You mean “foolproof”. This is the recommended method of dealing with > continuous streams like this. The only issue to consider is what > happens if the driver gets data while you are processing, in between the > completion and the next submission. If you have buffering in the > driver, that’s fine. If not, then you need to submit two read requests, > so there is still one waiting while you process the first. > >> One more query if we send a IRP_MJ_READ IRP followed by IRP_MJ_WRITE will >> these calls be queued in the destination driver ? will the IRP_MJ_WRITE >> be performed even if there is no data to be read and process IRP_MJ_READ. > > That’s up to the driver The system doesn’t know about any relationship > between read and write requests. You have to design the driver to do > what makes sense. > > – > Tim Roberts, xxxxx@probo.com > Providenza & Boekelheide, Inc. > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer
Hi,
I am still confused to go with the solution suggested as we will be loosing some packets.
I have to design NDIS-WDM driver, in the latest sample code provided (NETVMINI) in WDK simulates the lower edge HW, it does not sends the IRP as stated in the following link.
(NETVMINI : Microsoft Learn: Build skills that open doors in your career)
Is there any other solution to the problem I stated.