mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Oliver Neukum <oliver@neukum.org>
To: Duncan Sands <duncan.sands@math.u-psud.fr>
Cc: "Pete Zaitcev" <zaitcev@redhat.com>,
	"René Rebe" <rene@exactcode.de>,
	linux-kernel@vger.kernel.org
Subject: Re: MAX_USBFS_BUFFER_SIZE
Date: Fri, 3 Mar 2006 11:29:00 +0100	[thread overview]
Message-ID: <200603031129.00619.oliver@neukum.org> (raw)
In-Reply-To: <200603030912.11622.duncan.sands@math.u-psud.fr>

Am Freitag, 3. März 2006 09:12 schrieb Duncan Sands:
> > Have you ever considered how many TDs have to be allocated to transfer
> > a data buffer this big? No, seriously. If your application cannot deliver
> > the tranfer speeds with 16KB URBs, we ought to consider if the combination
> > of our USB stack, usbfs, libusb and the application ought to get serious
> > performance enhancing surgery. The problem is obviously in the software
> > overhead.
> 
> If you queue a large number of 16KB urbs, rather than one jumbo urb,
> does that make any difference to the number of TDs allocated?  I thought
> TDs were allocated for all queued urbs at the moment they are queued...

It changes the time the TDs are allocated. TDs allocated while an URB is
in flight don't hurt bandwidth. If your throughput is low because there
is too much delay between URBs, allocating many TDs makes matters worse.

	Regards
		Oliver

      reply	other threads:[~2006-03-03 10:29 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-01 20:16 MAX_USBFS_BUFFER_SIZE René Rebe
2006-03-01 20:53 ` MAX_USBFS_BUFFER_SIZE Oliver Neukum
2006-03-01 21:32 ` MAX_USBFS_BUFFER_SIZE Greg KH
2006-03-01 21:42   ` MAX_USBFS_BUFFER_SIZE René Rebe
2006-03-01 21:54     ` MAX_USBFS_BUFFER_SIZE Greg KH
2006-03-01 22:34       ` MAX_USBFS_BUFFER_SIZE Olivier Galibert
2006-03-01 22:41         ` MAX_USBFS_BUFFER_SIZE Greg KH
2006-03-01 23:25           ` MAX_USBFS_BUFFER_SIZE Olivier Galibert
2006-03-01 23:37             ` MAX_USBFS_BUFFER_SIZE Greg KH
2006-03-02  9:04       ` MAX_USBFS_BUFFER_SIZE René Rebe
2006-03-02 16:47         ` MAX_USBFS_BUFFER_SIZE Greg KH
2006-03-02 16:03       ` MAX_USBFS_BUFFER_SIZE René Rebe
2006-03-02 16:47         ` MAX_USBFS_BUFFER_SIZE Greg KH
2006-03-01 21:59     ` MAX_USBFS_BUFFER_SIZE Duncan Sands
2006-03-03 10:34       ` MAX_USBFS_BUFFER_SIZE Oliver Neukum
     [not found]   ` <mailman.1141249502.22706.linux-kernel2news@redhat.com>
2006-03-02 21:05     ` MAX_USBFS_BUFFER_SIZE Pete Zaitcev
2006-03-03  7:27       ` MAX_USBFS_BUFFER_SIZE René Rebe
2006-03-03 20:32         ` MAX_USBFS_BUFFER_SIZE Greg KH
2006-03-03  8:12       ` MAX_USBFS_BUFFER_SIZE Duncan Sands
2006-03-03 10:29         ` Oliver Neukum [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=200603031129.00619.oliver@neukum.org \
    --to=oliver@neukum.org \
    --cc=duncan.sands@math.u-psud.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rene@exactcode.de \
    --cc=zaitcev@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome