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:34:17 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@...el.com>
cc:	David Vrabel <david.vrabel@....com>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	AntonioLin <antonio.lin@...ormicro.com>,
	<linux-usb@...r.kernel.org>, <inaky@...ux.intel.com>
Subject: RE: Scatter-gather list constraints

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.

Alan Stern

--
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/