All of lore.kernel.org
 help / color / mirror / Atom feed
From: Inaky Perez-Gonzalez <inaky@linux.intel.com>
To: linux-usb-devel@lists.sourceforge.net
Cc: Alan Stern <stern@rowland.harvard.edu>,
	David Vrabel <david.vrabel@csr.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	AntonioLin <antonio.lin@alcormicro.com>,
	linux-usb@vger.kernel.org
Subject: Re: Scatter-gather list constraints
Date: Thu, 26 Jun 2008 15:39:25 -0700	[thread overview]
Message-ID: <200806261539.27469.inaky@linux.intel.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0806261531440.3893-100000@iolanthe.rowland.org>

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

      reply	other threads:[~2008-06-26 22:39 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-20 20:30 Scatter-gather list constraints Alan Stern
2008-06-20 20:50 ` David Miller
2008-06-21 13:59 ` Andi Kleen
2008-06-21 14:54   ` Alan Stern
2008-06-21 15:21     ` Andi Kleen
2008-06-21 21:50       ` Alan Stern
2008-06-21 23:00         ` Andi Kleen
2008-06-22 14:35           ` Alan Stern
2008-06-24 10:41         ` FUJITA Tomonori
2008-06-24 14:57           ` Alan Stern
2008-06-25  0:18             ` FUJITA Tomonori
2008-06-25 14:23               ` Alan Stern
2008-06-26  2:06                 ` FUJITA Tomonori
2008-06-26  5:39                   ` FUJITA Tomonori
2008-06-26  6:35                     ` Jens Axboe
2008-06-26  6:58                       ` FUJITA Tomonori
2008-06-26 12:39                         ` Jens Axboe
2008-06-26 12:54                           ` Andi Kleen
2008-06-26 13:00                             ` Jens Axboe
2008-06-26 15:12                           ` Alan Stern
2008-06-26 17:41                             ` Jens Axboe
2008-08-27 21:32                               ` Alan Stern
2008-06-26 15:16                           ` Boaz Harrosh
2008-06-26 17:39                             ` Jens Axboe
2008-06-26 14:18                       ` Alan Stern
2008-06-23 14:46 ` David Vrabel
2008-06-23 15:12   ` Alan Stern
2008-06-23 19:06     ` David Vrabel
2008-06-23 19:45       ` Alan Stern
2008-06-23 21:53         ` Stefan Richter
2008-06-25  4:02       ` Perez-Gonzalez, Inaky
2008-06-25 14:24         ` Alan Stern
2008-06-26 16:43           ` Perez-Gonzalez, Inaky
2008-06-26 19:34             ` Alan Stern
2008-06-26 22:39               ` Inaky Perez-Gonzalez [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200806261539.27469.inaky@linux.intel.com \
    --to=inaky@linux.intel.com \
    --cc=antonio.lin@alcormicro.com \
    --cc=david.vrabel@csr.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.