Linux USB
 help / color / mirror / Atom feed
From: Paul Cercueil <paul@crapouillou.net>
To: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Christian König" <christian.koenig@amd.com>
Cc: "Jonathan Cameron" <jic23@kernel.org>,
	"Nuno Sá" <noname.nuno@gmail.com>,
	"Michael Hennerich" <Michael.Hennerich@analog.com>,
	linux-usb@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
	"Paul Cercueil" <paul@crapouillou.net>
Subject: [PATCH v4 0/4] usb: gadget: functionfs: DMABUF import interface
Date: Wed, 17 Jan 2024 13:26:42 +0100	[thread overview]
Message-ID: <20240117122646.41616-1-paul@crapouillou.net> (raw)

Hi,

This is the v4 of my patchset that adds a new DMABUF import interface to
FunctionFS. It addresses the points that Daniel raised on the v3 - see
changelog below.

This interface is being used at Analog Devices, to transfer data from
high-speed transceivers to USB in a zero-copy fashion, using also the
DMABUF import interface to the IIO subsystem which is being upstreamed
in parallel [1]. The two are used by the Libiio software [2].

On a ZCU102 board with a FMComms3 daughter board, using the combination
of these two new interfaces yields a drastic improvement of the
throughput, from about 127 MiB/s using IIO's buffer read/write interface
+ read/write to the FunctionFS endpoints, to about 274 MiB/s when
passing around DMABUFs, for a lower CPU usage (0.85 load avg. before,
vs. 0.65 after).

Right now, *technically* there are no users of this interface, as
Analog Devices wants to wait until both interfaces are accepted upstream
to merge the DMABUF code in Libiio into the main branch, and Jonathan
wants to wait and see if this patchset is accepted to greenlight the
DMABUF interface in IIO as well. I think this isn't really a problem;
once everybody is happy with its part of the cake, we can merge them all
at once.

This is obviously for 5.9, and based on next-20240117.

Changelog:

- [3/4]:
  - Protect the dmabufs list with a mutex
  - Use incremental sequence number for the dma_fences
  - Unref attachments and DMABUFs in workers
  - Remove dead code in ffs_dma_resv_lock()
  - Fix non-block actually blocking
  - Use dma_fence_begin/end_signalling()
  - Add comment about cache-management and dma_buf_unmap_attachment()
  - Make sure dma_buf_map_attachment() is called with the dma-resv locked

Cheers,
-Paul

[1] https://lore.kernel.org/linux-iio/219abc43b4fdd4a13b307ed2efaa0e6869e68e3f.camel@gmail.com/T/
[2] https://github.com/analogdevicesinc/libiio/tree/pcercuei/dev-new-dmabuf-api

Paul Cercueil (4):
  usb: gadget: Support already-mapped DMA SGs
  usb: gadget: functionfs: Factorize wait-for-endpoint code
  usb: gadget: functionfs: Add DMABUF import interface
  Documentation: usb: Document FunctionFS DMABUF API

 Documentation/usb/functionfs.rst    |  36 ++
 drivers/usb/gadget/function/f_fs.c  | 500 ++++++++++++++++++++++++++--
 drivers/usb/gadget/udc/core.c       |   7 +-
 include/linux/usb/gadget.h          |   2 +
 include/uapi/linux/usb/functionfs.h |  41 +++
 5 files changed, 565 insertions(+), 21 deletions(-)

-- 
2.43.0


             reply	other threads:[~2024-01-17 12:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-17 12:26 Paul Cercueil [this message]
2024-01-17 12:26 ` [PATCH v4 1/4] usb: gadget: Support already-mapped DMA SGs Paul Cercueil
2024-01-19 21:49   ` Frank Li
2024-01-20  0:14     ` Paul Cercueil
2024-01-20  2:01       ` Frank Li
2024-01-17 12:26 ` [PATCH v4 2/4] usb: gadget: functionfs: Factorize wait-for-endpoint code Paul Cercueil
2024-01-17 12:26 ` [PATCH v4 3/4] usb: gadget: functionfs: Add DMABUF import interface Paul Cercueil
2024-01-17 13:15   ` Christian König
2024-01-19 13:10   ` kernel test robot
2024-01-19 14:25   ` kernel test robot
2024-01-17 12:26 ` [PATCH v4 4/4] Documentation: usb: Document FunctionFS DMABUF API Paul Cercueil

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=20240117122646.41616-1-paul@crapouillou.net \
    --to=paul@crapouillou.net \
    --cc=Michael.Hennerich@analog.com \
    --cc=christian.koenig@amd.com \
    --cc=corbet@lwn.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jic23@kernel.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=noname.nuno@gmail.com \
    --cc=sumit.semwal@linaro.org \
    /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