Alan Stern <[email protected]> writes:
> On Mon, 11 Apr 2016, Felipe Balbi wrote:
>
>> USB3 devices, because they are much newer, have much
>> less chance of having issues with larger transfers.
>> 
>> We still keep a limit because anything above 2048
>> sectors really rendered negligible speed
>> improvements, so we will simply ignore
>> that. Transferring 1MiB should already give us
>> pretty good performance.
>> 
>> Signed-off-by: Felipe Balbi <[email protected]>
>> ---
>>  drivers/usb/storage/scsiglue.c | 16 +++++++++++-----
>>  1 file changed, 11 insertions(+), 5 deletions(-)
>> 
>> diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
>> index 9da1fb3d0ff4..4512cf78a284 100644
>> --- a/drivers/usb/storage/scsiglue.c
>> +++ b/drivers/usb/storage/scsiglue.c
>> @@ -115,13 +115,19 @@ static int slave_configure(struct scsi_device *sdev)
>>  {
>>      struct us_data *us = host_to_us(sdev->host);
>>  
>> -    /* Many devices have trouble transferring more than 32KB at a time,
>> -     * while others have trouble with more than 64K. At this time we
>> -     * are limiting both to 32K (64 sectores).
>> -     */
>> -    if (us->fflags & (US_FL_MAX_SECTORS_64 | US_FL_MAX_SECTORS_MIN)) {
>> +    if (us->pusb_dev->speed >= USB_SPEED_SUPER) {
>> +            /* USB3 devices will be limited to 2048 sectors. This gives us
>> +             * better throughput on most devices.
>> +             */
>> +            blk_queue_max_hw_sectors(sdev->request_queue, 2048);
>> +    } else if (us->fflags & (US_FL_MAX_SECTORS_64 | US_FL_MAX_SECTORS_MIN)) 
>> {
>>              unsigned int max_sectors = 64;
>>  
>> +            /* Many devices have trouble transferring more than 32KB at a 
>> time,
>> +             * while others have trouble with more than 64K. At this time we
>> +             * are limiting both to 32K (64 sectores).
>> +             */
>> +
>>              if (us->fflags & US_FL_MAX_SECTORS_MIN)
>>                      max_sectors = PAGE_SIZE >> 9;
>>              if (queue_max_hw_sectors(sdev->request_queue) > max_sectors)
>
> I should have noticed this before.  If something goes wrong with the 
> 2048-sector limit, this doesn't permit the user to override.  Shouldn't 
> the test for USB_SPEED_SUPER go after the other FL_MAX_SECTORS tests?

you mean that a USB3 device with US_FL_MAX_SECTORS* should still respect
the 64 limit ? yeah I can do that. I'll send a new version tomorrow (so
I can wait for confirmation from you)

-- 
balbi

Attachment: signature.asc
Description: PGP signature

Reply via email to