Hi,
I want to implement flow control in my sample filter driver. Essentially I
want to hold incoming IRPs if my driver is not able to process them at that
rate (say because my driver exceeded its max. buffer capacity). In this
context I have some questions:
- If an IO (write) IRP comes to my volume filter driver (upperfilter), can
I queue it to an internal list and return STATUS_PENDING.
- Later I deque the IRP from internal list, and pass it down by calling
IoCallDriver(). Hereafter IRP follows the normal path including completion.
Is this possible? If not is there any alternate way to achieve this.
Some of the problems I see here are:
- Upper drivers would mark the IRP as pending though lower drivers have not
yet processed the IRP.
- How to handle IRP cancel(s)? (would IO Manager take care of this)
- Does IRP have any time-out kind of mechanism, in other words is it
expected that IRP should complete within a stipulated/max time.
Thanks,
Sunil
Comments inline:
“Sunil Patil” wrote in message news:xxxxx@ntdev:
> Hi,
>
> I want to implement flow control in my sample filter driver. Essentially I
> want to hold incoming IRPs if my driver is not able to process them at that
> rate (say because my driver exceeded its max. buffer capacity). In this
> context I have some questions:
>
> 1. If an IO (write) IRP comes to my volume filter driver (upperfilter), can
> I queue it to an internal list and return STATUS_PENDING.
> 2. Later I deque the IRP from internal list, and pass it down by calling
> IoCallDriver(). Hereafter IRP follows the normal path including completion.
>
> Is this possible? If not is there any alternate way to achieve this.
Yes you can do this.
>
> Some of the problems I see here are:
> 1. Upper drivers would mark the IRP as pending though lower drivers have not
> yet processed the IRP.
This will not matter.
> 2. How to handle IRP cancel(s)? (would IO Manager take care of this)
The I/O Manager will not take care of this. If you use KMDF the queue
mechanism can take care of it. If you really want to use WDM use the
IoCSQxxx calls for cancel safe queues.l
> 3. Does IRP have any time-out kind of mechanism, in other words is it
> expected that IRP should complete within a stipulated/max time.
>
IRP’s don’t have timeouts.
These are very basic questions, I strongly recommend you take a driver
class before diving in to mucking with the storage stack.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
At 14:03 05/07/2011, Don Burn wrote:
Comments inline:
“Sunil Patil” wrote in message news:xxxxx@ntdev:
>
>
>>3. Does IRP have any time-out kind of mechanism, in other words is it
>>expected that IRP should complete within a stipulated/max time.
>IRP’s don’t have timeouts.
>
Small point. IRP’s per se don’t have a timeout, however, NTFS does
have I/O timeouts. This used to be a fairly small timeout and was a
bug bear for SAN storage providers. With iSCSI there was a lot of
hardening in NTFS and I’ve seen it cope with breaks in I/O of over 2
minutes. I’ve no idea what the recoverable timeout is now, it may be
even longer.
The downside here is that when NTFS did timeout it wasn’t graceful,
it was a BSOD. So you do have a lot of leeway in queuing the I/O
IRPS in the filter but the only way you’ll know you’ve reached the
limit is with a crash.
Mark.
I have used an example of the computer-controlled hot water heater. I send
down a DeviceIoControl request for a temperature alert. If the water ever
goes overtemperature, the IRP is completed. Twice a year, the sun shines
through a window and onto the sensor, which is misinterpreted as the water
being overtemperature, and the IRP is completed. So even if there is no
overtemperature, the IRP is completed twice a year. Unless the day is
cloudy, in which case the IRP is not completed that day. It might be
completed once a year instead of twice a year, unless the other day six
months later is cloudy, also. If you want the concept of an IRP timing out,
it is your responsibility to add code to handle this, and if you don’t,
there can be no timeouts.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, July 05, 2011 9:04 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] sample flow control
Comments inline:
“Sunil Patil” wrote in message news:xxxxx@ntdev:
> Hi,
>
> I want to implement flow control in my sample filter driver.
> Essentially I want to hold incoming IRPs if my driver is not able to
> process them at that rate (say because my driver exceeded its max.
> buffer capacity). In this context I have some questions:
>
> 1. If an IO (write) IRP comes to my volume filter driver
> (upperfilter), can I queue it to an internal list and return
STATUS_PENDING.
> 2. Later I deque the IRP from internal list, and pass it down by
> calling IoCallDriver(). Hereafter IRP follows the normal path including
completion.
>
> Is this possible? If not is there any alternate way to achieve this.
Yes you can do this.
>
> Some of the problems I see here are:
> 1. Upper drivers would mark the IRP as pending though lower drivers
> have not yet processed the IRP.
This will not matter.
> 2. How to handle IRP cancel(s)? (would IO Manager take care of this)
The I/O Manager will not take care of this. If you use KMDF the queue
mechanism can take care of it. If you really want to use WDM use the
IoCSQxxx calls for cancel safe queues.l
> 3. Does IRP have any time-out kind of mechanism, in other words is it
> expected that IRP should complete within a stipulated/max time.
>
IRP’s don’t have timeouts.
These are very basic questions, I strongly recommend you take a driver class
before diving in to mucking with the storage stack.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
—
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
–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
>1. If an IO (write) IRP comes to my volume filter driver (upperfilter), can I queue it to an internal list and return
STATUS_PENDING.
Yes. And KMDF queues will help you a lot.
Is this possible?
Yes.
- Upper drivers would mark the IRP as pending though lower drivers have not yet processed the IRP.
- How to handle IRP cancel(s)? (would IO Manager take care of this)
Use IoCsqXxx or KMDF to do this.
- Does IRP have any time-out kind of mechanism
Generally, no.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com