mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christopher Li <usb-devel@chrisli.org>
To: Pete Zaitcev <zaitcev@redhat.com>
Cc: chrisl@vmware.com, linux-usb-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: PATCH] incrase usbdevfs bulk buffer size
Date: Sun, 2 Oct 2005 23:05:24 -0400	[thread overview]
Message-ID: <20051003030524.GA678@64m.dyndns.org> (raw)
In-Reply-To: <20051002211014.195ff1c3.zaitcev@redhat.com>

On Sun, Oct 02, 2005 at 09:10:14PM -0700, Pete Zaitcev wrote:
> On Sun, 2 Oct 2005 15:34:22 -0400, Christopher Li <usb-devel@chrisli.org> wrote:
> > 
> > I think the API is kind of fine in this aspect. The usbdevfs should be
> > able to take bigger than 16K, but the internal copy of the urb does not
> > have to use kmalloc on data buffers.
> 
> You miss an important detail here, namely that single URBs do not have
> a capability to transfer to a discotiguous buffer. As long as you try

That is exactly my point that the kernel should not limit itself on only
using contiguous buffers. Every USB controller can handle discrete DMA
buffer why shouldn't the kernel? Obviously it should be nice to address
the contiguous buffer restriction before bump up the bulk transfer limit.

> to map one transfer insive VMware to one URB, one and only one kmalloc

The current usbdevfs does a extra copy between from the user space urb
to the kernel space urb. So it does not matter if the user space urb is
contiguous or not. If the kernel can handle discrete dma internally,
the usbdevfs could use it and maintain it's current API.

BTW, That is not VMware choice how the data buffer was arranged. It is the guest.

> has to be done. But if splitting the transfer is acceptable, there is

I still think fixing the kernel to allow address scatter-getter buffer and
allow bigger buffer size is the right thing to do.

Chris


      reply	other threads:[~2005-10-03  6:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-01 20:20 [PATCH] " Christopher Li
2005-10-02 22:08 ` PATCH] " Pete Zaitcev
2005-10-02 19:34   ` Christopher Li
2005-10-03  4:10     ` Pete Zaitcev
2005-10-03  3:05       ` Christopher Li [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=20051003030524.GA678@64m.dyndns.org \
    --to=usb-devel@chrisli.org \
    --cc=chrisl@vmware.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --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