From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70D26C433EF for ; Sat, 4 Sep 2021 10:11:04 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 8F8DA6054E for ; Sat, 4 Sep 2021 10:11:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8F8DA6054E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=smartsharesystems.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8AD8740E3C; Sat, 4 Sep 2021 12:11:02 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id AC94640DDD for ; Sat, 4 Sep 2021 12:10:59 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 4 Sep 2021 12:10:55 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35C61A3A@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dpdk-dev] [PATCH v19 1/7] dmadev: introduce DMA device library public APIs Thread-Index: AdegxClpopAjnSkxRky+dVBn7m7nAQArvptA References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com> <1630588395-2804-1-git-send-email-fengchengwen@huawei.com> <1630588395-2804-2-git-send-email-fengchengwen@huawei.com> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Bruce Richardson" , "Chengwen Feng" Cc: , , , , , , , , , , , , , , Subject: Re: [dpdk-dev] [PATCH v19 1/7] dmadev: introduce DMA device library public APIs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson > Sent: Friday, 3 September 2021 15.04 >=20 > On Thu, Sep 02, 2021 at 09:13:09PM +0800, Chengwen Feng wrote: > > 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. > > > > Maintainers update is also included in this patch. > > > > Signed-off-by: Chengwen Feng > > Acked-by: Bruce Richardson > > Acked-by: Morten Br=F8rup > > Acked-by: Jerin Jacob > > --- > > 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 > +++++++++++++++++++++++++++++++++ > > 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 > > >=20 > >=20 > > +/** > > + * @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 > > + * to begin the operations previously enqueued by > rte_dmadev_copy/fill(). > > + * > > + * @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); > > + >=20 > Putting this out here for discussion: >=20 > 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). >=20 > 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]. >=20 > 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. >=20 > 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). >=20 > What are other people's thoughts or ideas on this? >=20 #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