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 98CA8A0548; Tue, 22 Jun 2021 21:17:44 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 18E3B4003F; Tue, 22 Jun 2021 21:17:44 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id A70074003E for ; Tue, 22 Jun 2021 21:17:41 +0200 (CEST) IronPort-SDR: LPj5lUouCyT1Gfnm2uCieGJKRWZrK4gPBxEABeqTBEkJ7NnBvEXGNVO2+cW9Kr+KVgobKs43FS 52V8VC/u23SQ== X-IronPort-AV: E=McAfee;i="6200,9189,10023"; a="228684950" X-IronPort-AV: E=Sophos;i="5.83,292,1616482800"; d="scan'208";a="228684950" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jun 2021 12:17:21 -0700 IronPort-SDR: vb4qHrcqrdGsiOZLcaKYh+SHjJVF6zYd3ZrXbZkMocMh8SkWVj0A+Hl3Ptng4RevIpK9wS6Bmc 4+a1C6AVBMqg== X-IronPort-AV: E=Sophos;i="5.83,292,1616482800"; d="scan'208";a="423433231" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.16.221]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 22 Jun 2021 12:17:15 -0700 Date: Tue, 22 Jun 2021 20:17:10 +0100 From: Bruce Richardson To: Jerin Jacob Cc: fengchengwen , Morten =?iso-8859-1?Q?Br=F8rup?= , Thomas Monjalon , Ferruh Yigit , dpdk-dev , Nipun Gupta , Hemant Agrawal , Maxime Coquelin , Honnappa Nagarahalli , Jerin Jacob , David Marchand , Satananda Burla , Prasun Kapoor Message-ID: References: <1623763327-30987-1-git-send-email-fengchengwen@huawei.com> <98CBD80474FA8B44BF855DF32C47DC35C61860@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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" On Tue, Jun 22, 2021 at 11:01:47PM +0530, Jerin Jacob wrote: > On Fri, Jun 18, 2021 at 3:25 PM Bruce Richardson > wrote: > > > > > > > Taking the case of a simple copy op, the parameters we need are: > > > > * src > > * dst > > * length > > OK. Is it the case where no other attribute that supported in HW or > you are not planning to > expose that through DPDK generic DMA API. > Only other parameters that might be needed can all be specified as flags, so all we need for a copy op is a general flags field for future expansion. > > > > Depending on the specific hardware there will also be passed in the > > descriptor a completion address, but we plan for these cases to always have > > the completions written back to a set location so that we have essentially > > ring-writeback, as with the hardware which doesn't explicitly have a > > separate completion address. Beyond that, I believe the only descriptor > > fields we will use are just the flags field indicating the op type etc. > > OK. In HW, we need to have IOVA for completion address that's only the > constraint. rest looks good to me. > That's like what we have, but I was not planning on exposing the completion address through the API at all, but have it internal to the driver and let the "completion" APIs just inform the app what is done or not. If we expose completion addresses, then that leaves the app open to having to parse different completion formats, so it needs to be internal IMHO. /Bruce