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 1803F426E8; Sun, 8 Oct 2023 04:33:19 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 97B3740263; Sun, 8 Oct 2023 04:33:18 +0200 (CEST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id 503484021F for ; Sun, 8 Oct 2023 04:33:16 +0200 (CEST) Received: from dggpeml100024.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4S35j96Wm2zTmNC for ; Sun, 8 Oct 2023 10:29:49 +0800 (CST) Received: from [10.67.121.161] (10.67.121.161) by dggpeml100024.china.huawei.com (7.185.36.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Sun, 8 Oct 2023 10:33:14 +0800 Subject: Re: [PATCH v1 1/3] dmadev: add inter-domain operations To: Anatoly Burakov , , Kevin Laatz , Bruce Richardson CC: Vladimir Medvedkin References: <8866a5c7ea36e476b2a92e3e4cea6c2c127ab82f.1691768110.git.anatoly.burakov@intel.com> From: fengchengwen Message-ID: <8ce1cf14-17e4-4092-1102-305f8fe25a36@huawei.com> Date: Sun, 8 Oct 2023 10:33:14 +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: <8866a5c7ea36e476b2a92e3e4cea6c2c127ab82f.1691768110.git.anatoly.burakov@intel.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.121.161] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpeml100024.china.huawei.com (7.185.36.115) X-CFilter-Loop: Reflected 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 Hi Anatoly, On 2023/8/12 0:14, Anatoly Burakov wrote: > Add a flag to indicate that a specific device supports inter-domain > operations, and add an API for inter-domain copy and fill. > > Inter-domain operation is an operation that is very similar to regular > DMA operation, except either source or destination addresses can be in a > different process's address space, indicated by source and destination > handle values. These values are currently meant to be provided by > private drivers' API's. > > This commit also adds a controller ID field into the DMA device API. > This is an arbitrary value that may not be implemented by hardware, but > it is meant to represent some kind of device hierarchy. > > Signed-off-by: Vladimir Medvedkin > Signed-off-by: Anatoly Burakov > --- ... > +__rte_experimental > +static inline int > +rte_dma_copy_inter_dom(int16_t dev_id, uint16_t vchan, rte_iova_t src, > + rte_iova_t dst, uint32_t length, uint16_t src_handle, > + uint16_t dst_handle, uint64_t flags) I would suggest add more general extension: rte_dma_copy*(int16_t dev_id, uint16_t vchan, rte_iova_t src, rte_iova_t dst, uint32_t length, uint64_t flags, void *param) The param only valid under some flags bits. As for this inter-domain extension: we could define inter-domain param struct. Whether add in current rte_dma_copy() API or add one new API, I think it mainly depend on performance impact of parameter transfer. Suggest more discuss for differnt platform and call specification. And last, Could you introduce the application scenarios of this feature? Thanks.