[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1407021630340.874-100000@iolanthe.rowland.org>
Date: Wed, 2 Jul 2014 16:40:27 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Peter Stuge <peter@...ge.se>
cc: Stefan Klug <stefan.klug@...lerweb.com>,
<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH][RFC] USB: zerocopy support for usbfs
On Wed, 2 Jul 2014, Peter Stuge wrote:
> > The kernel doesn't support scatter-gather for control transfers, only
> > bulk.
>
> That could possibly change, right, and then it would be nice to have
> zerocopy for free there as well?
No. ohci-hcd doesn't support control transfers larger than 4 KB
anyway, and ehci-hcd doesn't support control transfers larger than 16
KB. This is not likely to change. Besides, a control transfer can
never be larger than 64 KB, and throughput isn't an issue for them.
> > > Indeed I think userspace wants to be involved in choosing memory also
> > > with bulk, in order to ensure that zerocopy will always work when
> > > userspace cares about that.
> > >
> > > Is it enough to expose the DMA mask of the host controller?
> >
> > It doesn't need to be exposed, since the mmap(2) call would be handled
> > by the kernel's USB stack (and besides, the user program can't request
> > that the mapped memory be located in any particular physical address
> > region).
>
> Since alignment isn't the only issue I don't think there's a way to
> avoid it. I was just hoping to be able to avoid allocating zerocopy
> buffers with mmap().
How else can you guarantee that a buffer is located in the first 4 GB
of memory? Even on a 32-bit system (if the computer has more than 4 GB
of RAM)?
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/
Powered by blists - more mailing lists