The problem is the short transfer. Consider queuing 4 1K URBs. The device decides to only send us 2.5K of data, which will complete the first 2 URBs and then terminate the 3rd on a short packet.
But that's not an error. So the 4th URB will still run. And, since these
are all queued up, the code doesn't have a chance to cancel the 4th URB
fast enough.
And that can cause problems, including strange delays and transferring the
status data into a userspace buffer.
For what usb-storage needs, the scatter-gather segments really need to be a
single URB, with all the semantics therein.
Matt
On Sat, Nov 24, 2001 at 03:35:15PM -0800, David Brownell wrote:
> How about something simpler ... a convenience function
> that knows how to use the existing bulk queuing. It'd
> be a simple layer, no changes needed to the fragile host
> controller driver code. Something maybe like:
>
> int usb_submit_bulk_sg (
> // what device and endpoint
> struct usb_device *dev,
> int pipe,
> // mem alloc flags (used internally)
> int mem_flags,
> // urb flags, completion, context
> unsigned urb_flags,
> usb_complete_t complete,
> void *context,
> // the buffer
> struct scatterlist *data
> );
>
> Maybe some of those parameters should be wrapped up
> in a structure to make the API call seem simpler; that'd
> just be syntax sugar.
>
> If it turns out someday that layering that causes significant
> problems, things could always be rewritten underneath,
> but I think that a convenience function like that would be
> less likely to cause trouble.
>
> - Dave
>
>
> ----- Original Message -----
> From: "Matthew Dharm" <[EMAIL PROTECTED]>
> To: "Johannes Erdfelt" <[EMAIL PROTECTED]>; "David Brownell"
><[EMAIL PROTECTED]>; "USB
> Developers" <[EMAIL PROTECTED]>; "Greg KH" <[EMAIL PROTECTED]>
> Sent: Wednesday, November 21, 2001 11:55 PM
> Subject: Re: [linux-usb-devel] URB with scatter-gather?
>
> So, it's been a while since we looked at this....
>
> Would the HCD folks be willing to look at supporting scatter-gather via the
> API?
>
> Matt
>
> On Sat, Sep 22, 2001 at 05:54:54PM -0700, Matthew Dharm wrote:
> > Actually, the SCSI layer allocated sg elements in multiples of various
> > powers of 2, so I (luckily) don't have to worry about the "chunkyness"
> > problem.
> >
> > Frankly, I really don't care if we have to have some of the aforementioned
> > restrictions on sg lists -- I'd rather have working sg, and worry about
> > removing some of the more annoying restrictions later. Of course, I'm a
> > big fan of incremental development.... :)
> >
> > Matt
> >
> > On Sat, Sep 22, 2001 at 07:13:41PM -0400, Johannes Erdfelt wrote:
> > > On Wed, Sep 19, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> > > > If the driver submits a group of requests to of
> > > > sizes 16 bytes, 10 bytes, 14 bytes ... I'd expect
> > > > the driver to know the device would handle that!
> > > > And to be responsible for recovering in any case
> > > > where it couldn't.
> > > >
> > > > The USB transfer model is "chunky", and it'd
> > > > be error-prone (IMO) to try to present any
> > > > kind of non-chunky model to drivers.
> > >
> > > Absolutely. I'm just not sure that the SCSI layer will do that and more
> > > importantly if all USB storage devices will handle it gracefully.
> > >
> > > USB storage being the obvious first driver to take advantage of
> > > scatter/gather.
> > >
> > > JE
> > >
> > >
>
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
Your lips are twitching. You're playing Quake aren't you.
-- Stef to Greg
User Friendly, 8/11/1998
msg02685/pgp00000.pgp
Description: PGP signature
