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 40BF6A0C46; Tue, 7 Sep 2021 15:05:45 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B3CB3410EF; Tue, 7 Sep 2021 15:05:44 +0200 (CEST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id E3BC3410EC for ; Tue, 7 Sep 2021 15:05:42 +0200 (CEST) Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4H3ll46Blnz8yLY; Tue, 7 Sep 2021 21:01:20 +0800 (CST) Received: from dggpeml500024.china.huawei.com (7.185.36.10) by dggemv703-chm.china.huawei.com (10.3.19.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Tue, 7 Sep 2021 21:05:40 +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.2308.8; Tue, 7 Sep 2021 21:05:39 +0800 To: Bruce Richardson CC: , , , , , , , , , , , , , , , , References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com> <20210904101027.43252-1-fengchengwen@huawei.com> <20210904101027.43252-3-fengchengwen@huawei.com> From: fengchengwen Message-ID: Date: Tue, 7 Sep 2021 21:05:39 +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: dggems705-chm.china.huawei.com (10.3.19.182) To dggpeml500024.china.huawei.com (7.185.36.10) X-CFilter-Loop: Reflected Subject: Re: [dpdk-dev] [PATCH v20 2/7] dmadev: introduce DMA device library internal header 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" Already fix in V21, thanks On 2021/9/6 21:35, Bruce Richardson wrote: > On Sat, Sep 04, 2021 at 06:10:22PM +0800, Chengwen Feng wrote: >> This patch introduce DMA device library internal header, which contains >> internal data types that are used by the DMA devices in order to expose >> their ops to the class. >> >> Signed-off-by: Chengwen Feng >> Acked-by: Bruce Richardson >> Acked-by: Morten Brørup >> Reviewed-by: Kevin Laatz >> Reviewed-by: Conor Walsh >> --- > >> +struct rte_dmadev { >> + void *dev_private; >> + /**< PMD-specific private data. >> + * >> + * - If is the primary process, after dmadev allocated by >> + * rte_dmadev_pmd_allocate(), the PCI/SoC device probing should >> + * initialize this field, and copy it's value to the 'dev_private' >> + * field of 'struct rte_dmadev_data' which pointer by 'data' filed. >> + * >> + * - If is the secondary process, dmadev framework will initialize this >> + * field by copy from 'dev_private' field of 'struct rte_dmadev_data' >> + * which initialized by primary process. >> + * >> + * @note It's the primary process responsibility to deinitialize this >> + * field after invoke rte_dmadev_pmd_release() in the PCI/SoC device >> + * removing stage. >> + */ >> + rte_dmadev_copy_t copy; >> + rte_dmadev_copy_sg_t copy_sg; >> + rte_dmadev_fill_t fill; >> + rte_dmadev_submit_t submit; >> + rte_dmadev_completed_t completed; >> + rte_dmadev_completed_status_t completed_status; >> + void *reserved_ptr[7]; /**< Reserved for future IO function. */ > > This is new in this set, I think. I assume that 7 was chosen so that we > have the "data" pointer and the "dev_ops" pointers on the second cacheline > (if 64-byte CLs)? If so, I wonder if we can find a good way to express that > in the code or in the comments? > > The simplest - and probably as clear as any - is to split this into > "void *__reserved_cl0" and "void *__reserved_cl1[6]" to show that it is > split across the two cachelines, with the latter having comment: > "Reserve space for future IO functions, while keeping data and dev_ops > pointers on the second cacheline" > > If we don't mind using a slightly different type the magic "6" could be > changed to a computation: > char __reserved_cl1[RTE_CACHELINE_SZ - sizeof(void *) * 2]; > > However, for simplicity, I think the magic 6 can be kept, and just split > into reserved_cl0 and reserved_cl1 as I suggest above. > > /Bruce > > . >