mbox series

[v3,0/1] Zerocopy for USB Gadget FunctionFS

Message ID 20220209172507.97659-1-ingo.rohloff@lauterbach.com (mailing list archive)
Headers show
Series Zerocopy for USB Gadget FunctionFS | expand

Message

Ingo Rohloff Feb. 9, 2022, 5:25 p.m. UTC
The commit f7d34b445abc00e979b7 ("USB: Add support for usbfs zerocopy.")
added support for zerocopy operations for an USB Host via devio.c

The idea is to mmap buffers into user space, which are then filled
with data (either by the kernel for reads or by the user for writes).

Using these mmapped buffers avoids copying data between kernel space
and user space.

The patch proposed here, tries to do the same for a USB Gadget and a
user space application using USB Gaget FunctionFS.

Note: As long as you do not use mmap and/or libaio, FunctionFS should
behave exactly as before.

If you want to try out, user space demonstration code is here:

   https://github.com/trace32/test_usb_ffs



V3:
As requested: Use a spinlock instead of atomic64 to
tally the amount of used kernel memory by mmap calls.

ADDITIONALLY (compared to V2, meaning of limit == 0 changed):
The amount of memory user space processes might mmap, is per default
limited to 16 MiB per FunctionFS mount point.

This limit can be modified at the time FunctionFS is mounted, by using
the mount option "mmap_memory_mb=<value>", specifying the allowed mmap
space in MiB.  Example:

   mount -t functionfs -ommap_memory_mb=1 usb0 /usbfunc

In V3, a value of 0 for "mmap_memory_mb", means that mmap functionality
is DISABLED: All calls to mmap will return with -ENOMEM.

Rationale:
I can't think of a reason, why you should ever want to have UNLIMITED
mmap calls (this just means user-space can easily force the kernel to
kmalloc all space available).
Additionally: If you want a real high limit, just use
  mmap_memory_mb=1000000
or some similar big number.

In contrast: I think being able to forbid mmap might be useful.
So for V3: "mmap_memory_mb=0" means no mmap allowed (will always return
-ENOMEM).




V2:
The mmapped buffers are now associated with a "struct file *".

This is achieved by adding another in-between 
"struct ffs_ep_listener", which is allocated per "struct file *".

I believe I botched that up in the previous V1 proposal;

It seems using a list of mmapped segments associated to a 
"struct file *" is the right approach?



Ingo Rohloff (1):
  usb: gadget: f_fs: Support zerocopy transfers via mmap.

 drivers/usb/gadget/function/f_fs.c | 280 ++++++++++++++++++++++++++++-
 drivers/usb/gadget/function/u_fs.h |   7 +
 2 files changed, 281 insertions(+), 6 deletions(-)