mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Stuge <peter@stuge.se>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Stefan Klug <stefan.klug@baslerweb.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][RFC] USB: zerocopy support for usbfs
Date: Wed, 2 Jul 2014 20:49:33 +0200	[thread overview]
Message-ID: <20140702184933.7464.qmail@stuge.se> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1407021355060.874-100000@iolanthe.rowland.org>

Thank you very much for working on this, Stefan.

Alan Stern wrote:
> Also, many host controllers cannot handle arbitrary alignment.  
> It would be best to require that the buffer start at a page boundary.

This requires a bit of negotiation with userspace, maybe per-URB but
it seems better to negotiate per-claim or even per-open. What about
large control transfers?


> Using a global module parameter to control the use of zerocopy (for
> anything other than debugging or testing) is a bad idea.

I agree.


> If you think people will have a reason for avoiding zerocopy then
> you should make it possible to decide for each URB, by adding a new
> flag to struct usbdevfs_urb.

People might want to use zerocopy always, but have buffers in
userspace which make that impossible with the given hardware.

It's important that the kernel gives userspace enough information
about the constraints, if userspace wants zerocopy.


> People will want to use zerocopy with isochronous transfers as well as 
> bulk.  Implementing that isn't going to be quite so easy; it will be 
> necessary for the user to set up a memory mapping.  In fact, once 
> that's done the same mechanism could be used for bulk transfers too.

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?


//Peter

  reply	other threads:[~2014-07-02 18:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-02 15:53 Stefan Klug
2014-07-02 17:55 ` Greg KH
2014-07-03  7:06   ` Stefan Klug
2014-07-02 18:24 ` Alan Stern
2014-07-02 18:49   ` Peter Stuge [this message]
2014-07-02 19:31     ` Alan Stern
2014-07-02 19:42       ` Peter Stuge
2014-07-02 20:40         ` Alan Stern
2014-07-03  7:48   ` Stefan Klug
2014-07-03  8:40     ` David Laight
2014-07-03 14:15     ` Alan Stern
2014-07-02 18:58 ` Oliver Neukum
2014-07-02 19:38   ` Alan Stern
2014-07-03  8:22     ` Stefan Klug
2014-07-04  8:55 ` Oliver Neukum

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=20140702184933.7464.qmail@stuge.se \
    --to=peter@stuge.se \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stefan.klug@baslerweb.com \
    --cc=stern@rowland.harvard.edu \
    /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

all inboxes | Powered by JetHome®