Re: Maximum data size in a single transfer for MS driver

[James Bottomley <James.Bottomley-l3A5Bk7waGM@public.gmane.org>]

On Thu, 2010-02-18 at 11:24 -0500, Alan Stern wrote:
> On Thu, 18 Feb 2010, James Bottomley wrote:
> 
> > On Thu, 2010-02-18 at 14:16 +0530, Ramya Desai wrote:
> > > On Wed, Feb 17, 2010 at 8:32 PM, James Bottomley
> > > <James.Bottomley-l3A5Bk7waGM@public.gmane.org> wrote:
> > > 
> > > > I have no idea what the MS driver is, so it's impossible to answer
> > > > specifically.
> > > 
> > > MS means mass storage driver only.
> > 
> > OK, still don't know what that is ... but Randy decoded this for me; he
> > said you mean a driver under drivers/usb/storage?  
> 
> Yes, Ramya is talking about usb-storage.
> 
> > In that case, it looks like the helpers in protocol.c do use chaining
> > correctly (as long as the driver isn't doing direct dma), but there's a
> > clamp on the sg table size in scsiglue.c:
> > 
> > .sg_tablesize = SG_ALL
> > 
> > That would have to be changed to SCSI_MAX_SG_CHAIN_SEGMENTS to enable
> > chaining.
> 
> Is there any reason not to make this change in the standard kernel?  I 
> believe that the subdrivers which don't use the helpers in protocol.c 
> also handle chaining correctly.

As long as you're sure that's the case, it should be perfectly fine to
do this.  On some platforms you'll see the transfer sg list length jump
from 128 to 2048 ... so any drivers not using the protocol.c helpers not
only have to be using chaining ... they also have to have enough
hardware slots (or manually tune sg_tablesize themselves) ... this was
the reason why we've been raising the limit individually in SCSI drivers
(a lot can't handle the large sg list table sizes).

James


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html