From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C5341A0C48; Wed, 16 Jun 2021 09:09:18 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 41DE64067A; Wed, 16 Jun 2021 09:09:18 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 9060D40140 for ; Wed, 16 Jun 2021 09:09:17 +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: Wed, 16 Jun 2021 09:09:10 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35C61860@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dpdk-dev] [RFC PATCH] dmadev: introduce DMA device library Thread-Index: AddiBQzXm/sE/CCqTdeGvjdWpFEDowAdQkVw References: <1623763327-30987-1-git-send-email-fengchengwen@huawei.com> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Bruce Richardson" , "Chengwen Feng" Cc: , , , , , , , , , Subject: Re: [dpdk-dev] [RFC PATCH] dmadev: introduce DMA device library 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: Tuesday, 15 June 2021 18.39 >=20 > On Tue, Jun 15, 2021 at 09:22:07PM +0800, Chengwen Feng wrote: > > This patch introduces 'dmadevice' which is a generic type of DMA > > device. > > > > The APIs of dmadev library exposes some generic operations which can > > enable configuration and I/O with the DMA devices. > > > > Signed-off-by: Chengwen Feng > > --- > Thanks for sending this. >=20 > Of most interest to me right now are the key data-plane APIs. While we > are > still in the prototyping phase, below is a draft of what we are > thinking > for the key enqueue/perform_ops/completed_ops APIs. >=20 > Some key differences I note in below vs your original RFC: > * Use of void pointers rather than iova addresses. While using iova's > makes > sense in the general case when using hardware, in that it can work > with > both physical addresses and virtual addresses, if we change the APIs > to use > void pointers instead it will still work for DPDK in VA mode, while > at the > same time allow use of software fallbacks in error cases, and also a > stub > driver than uses memcpy in the background. Finally, using iova's > makes the > APIs a lot more awkward to use with anything but mbufs or similar > buffers > where we already have a pre-computed physical address. > * Use of id values rather than user-provided handles. Allowing the > user/app > to manage the amount of data stored per operation is a better > solution, I > feel than proscribing a certain about of in-driver tracking. Some > apps may > not care about anything other than a job being completed, while = other > apps > may have significant metadata to be tracked. Taking the user-context > handles out of the API also makes the driver code simpler. > * I've kept a single combined API for completions, which differs from > the > separate error handling completion API you propose. I need to give > the > two function approach a bit of thought, but likely both could work. > If we > (likely) never expect failed ops, then the specifics of error > handling > should not matter that much. >=20 > For the rest, the control / setup APIs are likely to be rather > uncontroversial, I suspect. However, I think that rather than xstats > APIs, > the library should first provide a set of standardized stats like > ethdev > does. If driver-specific stats are needed, we can add xstats later to > the > API. >=20 > Appreciate your further thoughts on this, thanks. >=20 > Regards, > /Bruce I generally agree with Bruce's points above. I would like to share a couple of ideas for further discussion: 1. API for bulk operations. The ability to prepare a vector of DMA operations, and then post it to = the DMA driver. 2. Prepare the API for more complex DMA operations than just copy/fill. E.g. blitter operations like "copy A bytes from the source starting at = address X, to the destination starting at address Y, masked with the = bytes starting at address Z, then skip B bytes at the source and C bytes = at the destination, rewind the mask to the beginning of Z, and repeat D = times". This is just an example. I'm suggesting to use a "DMA operation" union structure as parameter to = the command enqueue function, rather than having individual functions = for each possible DMA operation. I know I'm not the only one old enough on the mailing list to have = worked with the Commodore Amiga's blitter. :-) DPDK has lots of code using CPU vector instructions to shuffle bytes = around. I can easily imagine a DMA engine doing similar jobs, possibly = implemented in an FPGA or some other coprocessor. -Morten