Re: MaximumTransferLength in Storage Adapter

you can’t. How would that work? The hardware driver has said “the
largest block I can handle is 64 k”, and you want to hand it a 512k
block. What is the hardware driver supposed to do with that data?

On Friday, January 22, 2010, wrote:
>>Try to change following fields in PORT_CONFIGURATION_INFORMATION in driver
>
> How can i access PORT_CONFIGURATION_INFORMATION in the filter driver. Is there any way i can get access to these fields.
>
> madhu
>
> —
> 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
>


Mark Roddy

Ah, that is fine then. 64K is/was a fundamental block size unit for
many releases of the storage stack in nt. If you think you are
actually improving performance by coalescing upper 64K writes into
single 512K writes, and the lower driver has advertised a capability
to support 512K writes, and your ‘coalescing’ activity is not
violating any other assumptions or contracts between upper and lower
drivers you are filtering, then there is no problem. I think I have
laid out the basic nature of the landmines you are walking through.

Mark Roddy

On Fri, Jan 22, 2010 at 1:23 PM, wrote:
>>you can’t. How would that work? The hardware driver has said “the largest block I can handle is >64 k”, and you want to hand it a 512k block. What is the hardware driver supposed to do with that >data?
>
> In fact the hardware driver support 512K block. But the max block size i see in filter driver is 64K.
>
>
> —
> 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
>

Thank you for the reply.

Even if a filter driver modified the MaximumTransferLength and MaximumPhysicalPages fields returned by USBSTOR.SYS, I believe it should fail requests with STATUS_INVALID_PARAMETER if they exceed the internal MaximumTransferLength value used by USBSTOR.SYS. I don’t know how you could change that behavior with a filter driver.

You are correct. Even though there was a 512KB block size transfer the request failed with invalid parameter. I overlooked it.

There is a device instance specific USBSTOR.SYS registry flag that will change the MaximumTransferLength limit to 128KB and the MaximumPhysicalPages limit to 33. There is no existing mechanism to set these limits to arbitrary values.

Does this mean i cannot exceed transfer length of 128KB. Can you let me know which registry flag i need to change for a transfer length limit of 128KB.

Regards,
madhu


Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
https://signup.live.com/signup.aspx?id=60969

Thank for the support.

USBSTOR.SYS 128KB MaximumTransferLength registy setting:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbstor\VVVVPPPP]“DeviceHackFlags”=dword:00000008
Where VVVV = Device Descriptor idVendor in HEX
Where PPPP = Device Descriptor idProduct in HEX
* Applies to Windows XP Vista and above.

I had verified in Windows Vista and could see 128KB block transfer size.
However in Windows XP SP3 the block transfer size was 64KB even after adding registry keys.
Can you let me know if i need any additional configuration for Windows XP.

Regards
madhu


Hotmail: Free, trusted and rich email service.
https://signup.live.com/signup.aspx?id=60969

Actually “set by the user” is a real bad idea. Instead the hardware
should advertise what it can support and the port/class drivers should
respect those limits, with defaults for unadvertised limits
compatible with least capable devices.

The user has no idea what maxiumum transfer size is workable on any
particular device.

Mark Roddy

On Fri, Jan 29, 2010 at 9:09 AM, wrote:
> Thank you for the detailed explanation
>
>>* In the future, this registry setting shall be superseded by any other
> mechanism we introduce for the purpose of establishing the maximum transfer
> size. The new mechanism will take precedence.
>
> As you said a new mechanism is being proposed. I suggest not to restrict the maximum transfer size to 128KB. Even though the performance achieved is minor it should be easily set by the user.
>
> Regards,
> madhu
>
>
> —
> 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
>