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 F41E6A0C40; Thu, 29 Jul 2021 03:26:36 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7949840040; Thu, 29 Jul 2021 03:26:36 +0200 (CEST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id 4D7584003C for ; Thu, 29 Jul 2021 03:26:34 +0200 (CEST) Received: from dggemv711-chm.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4GZt7T6smMz81Yf; Thu, 29 Jul 2021 09:22:45 +0800 (CST) Received: from dggpeml500024.china.huawei.com (7.185.36.10) by dggemv711-chm.china.huawei.com (10.1.198.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 29 Jul 2021 09:26:31 +0800 Received: from [10.40.190.165] (10.40.190.165) by dggpeml500024.china.huawei.com (7.185.36.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 29 Jul 2021 09:26:31 +0800 To: Bruce Richardson CC: , , , , , , , , , , , , , , References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com> <1627357200-15291-1-git-send-email-fengchengwen@huawei.com> <1627357200-15291-2-git-send-email-fengchengwen@huawei.com> From: fengchengwen Message-ID: <9da78c1f-c2e4-cf71-9d07-dd539a16c1d0@huawei.com> Date: Thu, 29 Jul 2021 09:26:31 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.40.190.165] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpeml500024.china.huawei.com (7.185.36.10) X-CFilter-Loop: Reflected Subject: Re: [dpdk-dev] [PATCH v11 1/2] 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" Thanks, inline comment On 2021/7/28 19:13, Bruce Richardson wrote: > On Tue, Jul 27, 2021 at 11:39:59AM +0800, Chengwen Feng wrote: >> This patch introduce '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 >> Acked-by: Bruce Richardson >> Acked-by: Morten Brørup >> --- > > Thanks for this. Before it gets merged, I believe it needs to be split > further into multiple patches (say 4 or so) rather than adding the whole > lib in one go. > > Normally, I believe the split would be something like: > * basic device structures and infrastructure e.g. alloc and release > functions > * device config functions (and structures to go along with them) > such as configure and queue_setup > * data plane functions > I will try for it Maybe one patch for public file, one for pmd header file, one for implementation, and last for doc. > Documentation would be included in each of the patches, rather than done as > a block at the end. > > Besides that, I have one small additional requests for the API. Based off > feedback for ioat driver, we added in the following function to that API, > and we probably need something similar in dmadev: > > rte_ioat_burst_capacity() > > For our implementation this returns the number of elements that can be > enqueued to the ring, at least for the current burst/batch of packets. We > did the API this way because there can be additional limits beyond ring > size on each individual burst beyond just the raw ring capacity, e.g. even > if there are 4k ring elements free, there may be limits on the max burst > size the hardware can do, or limits on the number of outstanding > batches etc. > > Therefore can I request the addition of rte_dmadev_burst_capacity() [or > something similarly named] to the basic dmadev API set. For most hardware, > I think this will likely be the remaining free ring size, but I don't > believe the API should commit to that. The use case it was added for was to > enable an application which needs to do a multi-copy operation to check > that all copies can fit or not before enqueuing the first one. This is > important for hardware that doesn't have scatter-gather list support. Remaining capacity can be inferred by ring_idx which return from enqueue and dequeue APIs. So I don't think this API needs to be added. For scatter-gather list, there maybe a hardware limit for max src or dst entry size, I prefer add 'max_sges' filed in struct rte_dmadev_info to indicate it. > > /Bruce > > PS: One typo in code flagged below too. > > >> + */ >> +enum rte_dma_status_code { >> + RTE_DMA_STATUS_SUCCESSFUL, >> + /**< The operation completed successfully. */ >> + RTE_DMA_STATUS_USRER_ABORT, > > Typo here ^^^ > OK, USRER->USER will fix later > . >