Re: Infrastructure for zerocopy I/O

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 17 Nov 2015, Christoph Hellwig wrote:

> On Mon, Nov 16, 2015 at 03:22:06PM -0500, Alan Stern wrote:
> > In other words, you're suggesting we do this:
> > 
> > 	Check that userspace requested zerocopy (otherwise the user 
> > 	program might try to access other data stored in the same cache 
> > 	lines as the buffer while the I/O is in progres);
> > 
> > 	Call get_user_pages (or get_user_pages_fast? -- it's not clear 
> > 	which should be used) for this buffer;
> > 
> > 	Use the array of pages returned by that routine to populate
> > 	a scatter-gather list (sg_alloc_table_from_pages);
> > 
> > 	Pass that list to dma_map_sg.
> > 
> > Is that right?
> 
> Yes.
> 
> > Does dma_map_sg check the page addresses against the DMA mask and
> > automatically create a bounce buffer, or do we have to do that
> > manually?  Documentation/DMA-API-HOWTO.txt doesn't discuss this.
> 
> You need to do this manually.

I looked through the code. Christoph was wrong about this, at least on 
systems that support CONFIG_SWIOTLB.  Of course, using a bounce buffer 
kind of defeats the purpose of zerocopy I/O, but I guess sometimes 
there's no choice.

AFAICT this leaves two questions.  First, should we worry about systems
that don't support SWIOTLB?  My feeling is probably not.  In fact, the
existing DMA mapping code used for ordinary USB communications doesn't
try to handle mapping errors by setting up bounce buffers; it assumes
that dma_map_sg() takes care of all that.

Second, how shall we ask user programs to indicate that they won't
access the buffer's memory pages during I/O?  My suggestion is that we
add a USBDEVFS_URB_ZEROCOPY flag (and a corresponding capability bit).  
Any objections?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux