From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1TiA2r-0001rI-Q1 for mharc-grub-devel@gnu.org; Mon, 10 Dec 2012 15:33:45 -0500 Received: from eggs.gnu.org ([208.118.235.92]:57255) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiA2p-0001qm-QH for grub-devel@gnu.org; Mon, 10 Dec 2012 15:33:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TiA2o-00073O-9M for grub-devel@gnu.org; Mon, 10 Dec 2012 15:33:43 -0500 Received: from mail-bk0-f41.google.com ([209.85.214.41]:52266) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiA2n-000739-VC for grub-devel@gnu.org; Mon, 10 Dec 2012 15:33:42 -0500 Received: by mail-bk0-f41.google.com with SMTP id jg9so1427295bkc.0 for ; Mon, 10 Dec 2012 12:33:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; bh=Do+ZrSD52CMh8li0y/BCHTfH6SbbGRNoDzZf8TA2Cjw=; b=ldmbdc2gKzrvRomYci7g6zpWRWP3vztAkQTQFfWTq3svB6eoihaWO8NYCIKpoaMttA Za4K6lK2iALpRdvEKTUX2GnaHXqxqeajOyeudpJHIq8rIgZGdj83LBgz8htLyQBV4IMy OcN61JQf4oayP5HOREjqHXKTUuQq6HBieOQRFoILJu626UQ+H6HUDlAOa58v2qLgXKan qlDdzhApWp+U6XwBV8Gu+5xYB9f2t8UoxWPiCfrAtRzBR2mCqxeXV9ATfyLtAPzPgqeS /vw+XD0JPQJlmt8ecpvsyEavSR1/DnMMQ3BiZZmDLJgf0/ROzoZFLfCTPBxb5OazJcIv c64g== Received: by 10.204.9.23 with SMTP id j23mr4849549bkj.2.1355171620961; Mon, 10 Dec 2012 12:33:40 -0800 (PST) Received: from debian.x201.phnet (125-234.197-178.cust.bluewin.ch. [178.197.234.125]) by mx.google.com with ESMTPS id i20sm15264712bkw.5.2012.12.10.12.33.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Dec 2012 12:33:39 -0800 (PST) Message-ID: <50C6471F.9060108@gmail.com> Date: Mon, 10 Dec 2012 21:33:35 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: [PATCH] Long USB transfers problem References: <1354402009.2479.108.camel@pracovna> <50C5C028.7000700@gmail.com> <1355161748.2527.94.camel@pracovna> In-Reply-To: <1355161748.2527.94.camel@pracovna> X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigC1A5B004A98A0A0C20F90C4D" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.214.41 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 20:33:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC1A5B004A98A0A0C20F90C4D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10.12.2012 18:49, Ale=C5=A1 Nesrsta wrote: > Vladimir '=CF=86-coder/phcoder' Serbinenko p=C3=AD=C5=A1e 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 >=20 > 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 o= f > 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... >=20 > 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. >=20 > 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. >=20 >=20 >> 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 storag= e > device, e.g. we can put splitting logic in scsi.c. >=20 > 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. >=20 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 =3D 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. >=20 > BR, > Ales >=20 >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enigC1A5B004A98A0A0C20F90C4D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAlDGRx8ACgkQNak7dOguQgkoLAD9FsHIgPrNvGbYQy6CLwqLrOEp 4vVnW6uNade8GeDpFqoBALahSfiGgimCNgULNIzYzP3Unqf1uAWbwJEjaUSrckPi =0fOj -----END PGP SIGNATURE----- --------------enigC1A5B004A98A0A0C20F90C4D--