Re: [PATCH] Long USB transfers problem

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3259 bytes --]

On 10.12.2012 18:49, Aleš Nesrsta wrote:

> Vladimir 'φ-coder/phcoder' Serbinenko píše v Po 10. 12. 2012 v 11:57
> That is very good question but I probably cannot say definite answer.
> Theoretically we have two possible low limits related to each USBMS
> device:
> - SCSI device block size (sector size)
> - USB device maximal packet size
> 
> I think - according to general USB specification - that the partial
> intermediate bulk transfer of "large" data block can be any multiple of
> endpoint wMaxPacketSize which is lower than or equal to unread length of
> data.
> But wMaxPacketSize itself is too low value in case of USB 1 devices, we
> need some larger value to be more effective - i.e. at least we should
> choose some multiplier...
> 
> So, probably better will be to use SCSI device block (sector) size.
> Valid SCSI device block size should be included in data structure
> returned by device as answer to Read Capacity X - this value is read by
> grub_scsi_open function during USBMS device initialization.
> 
> Using of SCSI block size will be possible only in case of USB mass
> storage device - but it is probably not problem, see my answer to Your
> second question.
> 
> 
>> Also do we have any other use for long USB transfers? If not, it's
>> easier to put this logic in scsi.c rather than adding it another time in
>> USB subsystem.
> Currently GRUB supports only these three kind of USB devices:
> - mass storage
> - keyboard
> - two USB-serial converters
> Keyboard uses very short interrupt data blocks, serial converter
> probably should not use longer bulk transfer than its internal buffer
> size, i.e. around 256 bytes.
> So, there is probably only one source of "long" transfers - mass storage
> device, e.g. we can put splitting logic in scsi.c.
> 
> There is only one question, if scsi.c is really right place - scsi.c
> could be potentially used for another kind of devices than USBMS and if
> we split "long" transfers in scsi.c, we can lost performance on such
> another devices.
> 

We already have:
      /* PATA doesn't support more than 32K reads.
	 Not sure about AHCI and USB. If it's confirmed that either of
	 them can do bigger reads reliably this value can be moved to 'scsi'
	 structure.  */
      grub_size_t len = 32768 >> disk->log_sector_size;

So it would be that maximum transfer size would be part of structure.
Another 2 questions are:
1) Is this multi-schedule transfer reliable? What if we fail to add QD's
in time?
2) Do such transfers work with other device, in particular the ones we
may be interested in in the future?

> As this problem is together USB implementation specific and USB mass
> storage specific, I suggest to do splitting in usbms.c.
> Functions grub_usbms_read and grub_usbms_write have access to related
> grub_scsi structure, i.e. splitting in these functions can use SCSI
> device block size of related USB mass storage device without any
> additional modifications.
> 
> BR,
> Ales
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel



-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]