linux-kernel - Re: Scatter-gather list constraints

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 26 Jun 2008 15:39:25 -0700
From:	Inaky Perez-Gonzalez <inaky@...ux.intel.com>
To:	linux-usb-devel@...ts.sourceforge.net
Cc:	Alan Stern <stern@...land.harvard.edu>,
	David Vrabel <david.vrabel@....com>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	AntonioLin <antonio.lin@...ormicro.com>,
	linux-usb@...r.kernel.org
Subject: Re: Scatter-gather list constraints

On Thursday 26 June 2008, Alan Stern wrote:
> On Thu, 26 Jun 2008, Perez-Gonzalez, Inaky wrote:
> 
> > For WA, when we get a buffer to be sent from a URB, it has to be split
> > in chunks, each chunk has a header added. So we end up with a list of
> > chunks, most of them quite small. Each requires a single URB to send.
> > resources galore.
> > 
> > If we could queue all those, the overhead would be reduced to allocating
> > the headers (possibly in a continuous array) and the sg "descriptors"
> > to describe the whole thing.
> > 
> > However, the alignment stuff somebody mentioned in another email in this
> > thread might cause problems.
> > 
> > At the end it might not be all that doable (I might be missing some
> > subtle isssues), but it is well worth a look.
> > 
> > >Note that usbcore already contains a scatter-gather library.
> > >(Unfortunately the library is limited in usefulness because it needs to
> > >run in process context.)
> > 
> > And the overhead of one URB per sg "node" kills it's usability for
> > WAs.
> 
> For this case (lots of small chunks making up a single URB), using a 
> bounce buffer might well be the easiest solution.  It depends on the 
> size of the URB and the number and sizes of the small chunks.  There 
> would be a lot less overhead -- only one URB -- and one large memory
> allocation instead of lots of small ones.

That's what we have right now (if I rememeber correctly); the issue
is that you end up copying A LOT. I don't know, maybe I am just being
overperfectionist. The data chunks (segments) can be up to (digs)
3584 [from 512, in 512 increments] if I am reading the spec right 
(WUSB1.0 4.5.1). Interleaving that with small chunks and change...
I don't know if that much copying will end up being that good, along
with the allocations it requires, etc.

-- 
Inaky
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/