From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
Sent: Friday, 3 September 2021 15.04

On Thu, Sep 02, 2021 at 09:13:09PM +0800, Chengwen Feng wrote:

quoted

The 'dmadevice' is a generic type of DMA device.

This patch introduce the 'dmadevice' public APIs which expose generic
operations that can enable configuration and I/O with the DMA

devices.

quoted

Maintainers update is also included in this patch.

Signed-off-by: Chengwen Feng <redacted>
Acked-by: Bruce Richardson <redacted>
Acked-by: Morten Brørup <redacted>
Acked-by: Jerin Jacob <redacted>
---
 MAINTAINERS                            |   4 +
 doc/api/doxy-api-index.md              |   1 +
 doc/api/doxy-api.conf.in               |   1 +
 doc/guides/rel_notes/release_21_11.rst |   5 +
 lib/dmadev/meson.build                 |   4 +
 lib/dmadev/rte_dmadev.h                | 949

+++++++++++++++++++++++++++++++++

quoted

 lib/dmadev/version.map                 |  24 +
 lib/meson.build                        |   1 +
 8 files changed, 989 insertions(+)
 create mode 100644 lib/dmadev/meson.build
 create mode 100644 lib/dmadev/rte_dmadev.h
 create mode 100644 lib/dmadev/version.map

<snip>

quoted

+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Trigger hardware to begin performing enqueued operations.
+ *
+ * This API is used to write the "doorbell" to the hardware to

trigger it

quoted

+ * to begin the operations previously enqueued by

rte_dmadev_copy/fill().

quoted

+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param vchan
+ *   The identifier of virtual DMA channel.
+ *
+ * @return
+ *   0 on success. Otherwise negative value is returned.
+ */
+__rte_experimental
+int
+rte_dmadev_submit(uint16_t dev_id, uint16_t vchan);
+

Putting this out here for discussion:

Those developers here looking at how integration of dma acceleration
into
vhost-virtio e.g. for OVS use, have come back with the request that we
provide a method for querying the amount of space in the descriptor
ring,
or the size of the next burst, or similar. Basically, the reason for
the
ask is to allow an app to determine if a set of jobs of size N can be
enqueued before the first one is, so that we don't get a half-offload
of
copy of a multi-segment packet (for devices where scatter-gather is not
available).

In our "ioat" rawdev driver, we did this by providing a
"burst_capacity"
API which returned the number of elements which could be enqueued in
the
next burst without error (normally the available ring space). Looking
at
the dmadev APIs, an alternative way to do this is to extend the
"submit()"
function to allow a 3rd optional parameter to return this info. That
is,
when submitting one burst of operations, you get info about how many
more
you can enqueue in the next burst. [For submitting packets via the
submit
flag, this info would not be available, as I feel ending all enqueue
operations would be excessive].

Therefore, I see a number of options for us to meet the ask for space
querying API:
1. provide a capacity API as done with ioat driver
2. provide (optional) capacity information from each submit() call
3. provide both #1 and #2 above as they are compatible
4. <some other idea>

For me, I think #3 is probably the most flexible approach. The benefit
of
#2 is that the info can be provided to the application much more
cheaply
than when the app has to call a separate API (which wouldn't be on the
fast-path). However, a way to provide the info apart from submitting a
burst would also be helpful, hence adding the extra function too (#1).

What are other people's thoughts or ideas on this?

#2 Is low cost. However, the information about the remaining capacity quickly becomes outdated if not used immediately, so we also need #1.

And #1 can be also used from slow path, e.g. for telemetry purposes.

So I vote for providing #1 and optionally #2.

I also considered if a _bulk function would be useful in addition to the _burst function. But I think that the fast path application's decision is not binary (i.e. use DMA or not), the fast path application would want to process as many as possible by DMA and then process the remaining by software.

-Morten