Date: Sun, 2 Oct 2005 21:10:14 -0700
From: Pete Zaitcev <zaitcev@redhat.com>
To: Christopher Li <usb-devel@chrisli.org>
Cc: chrisl@vmware.com, linux-usb-devel@lists.sourceforge.net,
       linux-kernel@vger.kernel.org, zaitcev@redhat.com
Subject: Re: PATCH] incrase usbdevfs bulk buffer size
Message-Id: <20051002211014.195ff1c3.zaitcev@redhat.com>
In-Reply-To: <20051002193422.GH3453@64m.dyndns.org>
References: <20051001202059.GE3453@64m.dyndns.org>
	<20051002150829.35107f91.zaitcev@redhat.com>
	<20051002193422.GH3453@64m.dyndns.org>
Organization: Red Hat, Inc.
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1113
Lines: 24

On Sun, 2 Oct 2005 15:34:22 -0400, Christopher Li <usb-devel@chrisli.org> wrote:

> > 16K is an order 2 allocation on systems with 4KB pages, such as
> > Opteron. It kinda sorta works, but not really.
> > 
> > This looks like a requirement to think about a better API. []
> 
> 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
to map one transfer insive VMware to one URB, one and only one kmalloc
has to be done. But if splitting the transfer is acceptable, there is
no reason to up the maximum buffer size in usbfs. But the above is IMHO
only, and perhaps I miss something as well.

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