IRP Queue Size

Hi OSR online community

I have 2 questions.

  1. What is the size of IRP queue for a device? How can it be decided? Does it have fixed length for every device or endless size until it is filled up?? I couldn’t find any official documentation for IRP queue size.
  2. If UM code produces data very fast, it can overflood the IRP queue right? For such situation, is there any API for back pressure control? How do you handle fast producer, slow consumer problem in a windows driver??

Thanks…

There is no limit to the IRP they are allocated on the fly so memory size becomes the constraint. Why do you feel that your user space program will swamp the device? Yes you can do a large number of asynchronous writes, but normally there are other interactions.

You should be aware that a common driver being driven by a single thread with minimum work to do in the driver is going to be limited to less100,000 requests / second unless you start doing various optimizations for the driver.

Remember that every I/O request requires a user/kernel/user excursion. That, plus the overhead of validation and processing the IRP, act as a throttle on the submissions. Also remember that the first part of the I/O processing is done on the caller’s thread. So, the driver does have a certain say in the submission rate.

1 Like

There’s no limit to the size of the queue. Depending on the type of request, there can be other considerations (such as the amount of non-paged pool available).

You should be aware that a common driver being driven by a single thread with minimum work to do in the driver is going to be limited to less100,000 requests / second

This does not match my experience. I’ve regularly seen throughput at least a factor of magnitude greater. Then again, I ant say I’ve actually benchmarked this recently, either.

Peter

Peter, the last time I benchmarked this with a KMDF driver with nothing special was in the range of 100,000 requests per second with a single thread driving things and actually hitting hardware. Adding threads to the user space program, or taking advantage of a number optimizations one can make by stepping partially or fully for the specific request path only out of the KMDF framework can push things much higher.

Well…. Now you have me curious.

I’m going to take the KMDF Nothing driver that we use in WDF class, and see how many read requests I can push through it per second… should be interesting.

Peter

(and, of course, I’ve been dragged-off into two other unrelated projects today… I haven’t forgotten, I’ve just be “otherwise directed”)