Hi guys,
Suppose on EvtIoRead the length of the user buffer (retrieved via Length parameter) is greater than what my (USB) driver can currently handle. Is there an ideal way to handle such scenarios?
Currently, we just complete the request with a status of STATUS_INVALID_DEVICE_REQUEST. I’m also curious if there is an ideal buffer size recommended for USB devices (like 2048, 4098, etc.) assuming we’re using a USB 2.0 compatible device.
xxxxx@gmail.com wrote:
Suppose on EvtIoRead the length of the user buffer (retrieved via Length parameter) is greater than what my (USB) driver can currently handle. Is there an ideal way to handle such scenarios?
Why would your driver possibly have a limit? If you look at the bulkusb
sample, you’ll see that they handle by submitting about 2MB at a time.
In the completion routine, if the buffer isn’t completed, you just
submit the next 2MB. You need to end it early you get a short transfer,
as usual.
Currently, we just complete the request with a status of STATUS_INVALID_DEVICE_REQUEST. I’m also curious if there is an ideal buffer size recommended for USB devices (like 2048, 4098, etc.) assuming we’re using a USB 2.0 compatible device.
The documented limit for a single bulk IRP 4MB for high-speed devices.
There is no reason to limit things any more than that. Usually, the
request size is determined by the device’s purpose, not by an arbitrary
number.
https://msdn.microsoft.com/en-us/library/windows/hardware/ff538112.aspx
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
After Tim’s questions about why you’d have a limit …
Your driver might be able to split the request up - get one request from the client for N+M bytes (N = max, M <= N) and issue 2 sequential requests - one for N bytes and then one for M. if you can split up the operation like that - sometimes you can and sometimes you can’t.
If not, your driver could just return less data than was requested. You use the Information field to communicate back to the IO manager how many bytes of data you are returning, and that can be less than the number requested.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, January 21, 2015 10:39 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Ideal behavior when user-app buffer is more than expected
xxxxx@gmail.com wrote:
Suppose on EvtIoRead the length of the user buffer (retrieved via Length parameter) is greater than what my (USB) driver can currently handle. Is there an ideal way to handle such scenarios?
Why would your driver possibly have a limit? If you look at the bulkusb sample, you’ll see that they handle by submitting about 2MB at a time.
In the completion routine, if the buffer isn’t completed, you just submit the next 2MB. You need to end it early you get a short transfer, as usual.
Currently, we just complete the request with a status of STATUS_INVALID_DEVICE_REQUEST. I’m also curious if there is an ideal buffer size recommended for USB devices (like 2048, 4098, etc.) assuming we’re using a USB 2.0 compatible device.
The documented limit for a single bulk IRP 4MB for high-speed devices.
There is no reason to limit things any more than that. Usually, the request size is determined by the device’s purpose, not by an arbitrary number.
https://msdn.microsoft.com/en-us/library/windows/hardware/ff538112.aspx
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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
Return what can be read. If you handle it properly, you should get reads
for the additional bytes.
On Wed, Jan 21, 2015 at 2:03 PM, Peter Wieland
wrote:
> After Tim’s questions about why you’d have a limit …
>
> Your driver might be able to split the request up - get one request from
> the client for N+M bytes (N = max, M <= N) and issue 2 sequential requests
> - one for N bytes and then one for M. if you can split up the operation
> like that - sometimes you can and sometimes you can’t.
>
> If not, your driver could just return less data than was requested. You
> use the Information field to communicate back to the IO manager how many
> bytes of data you are returning, and that can be less than the number
> requested.
>
> -p
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Tim Roberts
> Sent: Wednesday, January 21, 2015 10:39 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Ideal behavior when user-app buffer is more than
> expected
>
> xxxxx@gmail.com wrote:
> > Suppose on EvtIoRead the length of the user buffer (retrieved via Length
> parameter) is greater than what my (USB) driver can currently handle. Is
> there an ideal way to handle such scenarios?
>
> Why would your driver possibly have a limit? If you look at the bulkusb
> sample, you’ll see that they handle by submitting about 2MB at a time.
> In the completion routine, if the buffer isn’t completed, you just submit
> the next 2MB. You need to end it early you get a short transfer, as usual.
>
>
> > Currently, we just complete the request with a status of
> STATUS_INVALID_DEVICE_REQUEST. I’m also curious if there is an ideal buffer
> size recommended for USB devices (like 2048, 4098, etc.) assuming we’re
> using a USB 2.0 compatible device.
>
> The documented limit for a single bulk IRP 4MB for high-speed devices.
> There is no reason to limit things any more than that. Usually, the
> request size is determined by the device’s purpose, not by an arbitrary
> number.
>
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff538112.aspx
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
–
Jamey Kirby
Disrupting the establishment since 1964
This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.
Thanks for all of your responses Tim, Peter, and James. According to our tests it seems like the transfer speed is limited mostly by the user-apps buffer size, increasing it results in faster transfer speeds.