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 4188FA0C4B; Fri, 15 Oct 2021 11:59:33 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2F64E410F1; Fri, 15 Oct 2021 11:59:33 +0200 (CEST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id ED66340692 for ; Fri, 15 Oct 2021 11:59:31 +0200 (CEST) Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4HW1p616n4z909m; Fri, 15 Oct 2021 17:54:38 +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; Fri, 15 Oct 2021 17:59:19 +0800 Received: from [127.0.0.1] (10.67.100.224) 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; Fri, 15 Oct 2021 17:59:19 +0800 To: Thomas Monjalon CC: , , , , , , , , , , , , , , , , References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com> <0e44a184-3540-bb2e-28c7-ba4b0fc4df98@huawei.com> <1801913.4R2s7ZJTnX@thomas> <2810284.T8RqjUy1RU@thomas> From: fengchengwen Message-ID: <73748677-58a7-34f6-56f5-0e2b090f669a@huawei.com> Date: Fri, 15 Oct 2021 17:59:18 +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: <2810284.T8RqjUy1RU@thomas> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.100.224] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpeml500024.china.huawei.com (7.185.36.10) X-CFilter-Loop: Reflected Subject: Re: [dpdk-dev] [PATCH v25 1/6] 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 2021/10/15 16:29, Thomas Monjalon wrote: > 13/10/2021 09:41, Thomas Monjalon: >> 13/10/2021 02:21, fengchengwen: >>> On 2021/10/13 3:09, Thomas Monjalon wrote: >>>> 11/10/2021 09:33, Chengwen Feng: >>>>> +static void >>>>> +dma_release(struct rte_dma_dev *dev) >>>>> +{ >>>>> + rte_free(dev->dev_private); >>>>> + memset(dev, 0, sizeof(struct rte_dma_dev)); >>>>> +} >> [...] >>>>> +int >>>>> +rte_dma_pmd_release(const char *name) >>>>> +{ >>>>> + struct rte_dma_dev *dev; >>>>> + >>>>> + if (dma_check_name(name) != 0) >>>>> + return -EINVAL; >>>>> + >>>>> + dev = dma_find_by_name(name); >>>>> + if (dev == NULL) >>>>> + return -EINVAL; >>>>> + >>>>> + dma_release(dev); >>>>> + return 0; >>>>> +} >>>> >>>> Trying to understand the logic of creation/destroy. >>>> skeldma_probe >>>> \-> skeldma_create >>>> \-> rte_dma_pmd_allocate >>>> \-> dma_allocate >>>> \-> dma_data_prepare >>>> \-> dma_dev_data_prepare >>>> skeldma_remove >>>> \-> skeldma_destroy >>>> \-> rte_dma_pmd_release >>>> \-> dma_release >>> >>> This patch only provide device allocate function, the 2st patch provide extra logic: >>> >>> diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c >>> index 42a4693bd9..a6a5680d2b 100644 >>> --- a/lib/dmadev/rte_dmadev.c >>> +++ b/lib/dmadev/rte_dmadev.c >>> @@ -201,6 +201,9 @@ rte_dma_pmd_release(const char *name) >>> if (dev == NULL) >>> return -EINVAL; >>> >>> + if (dev->state == RTE_DMA_DEV_READY) >>> + return rte_dma_close(dev->dev_id); >>> + >>> dma_release(dev); >>> return 0; >>> } >>> >>> So the skeldma remove will be: >>> >>> skeldma_remove >>> \-> skeldma_destroy >>> \-> rte_dma_pmd_release >>> \-> rte_dma_close >>> \-> dma_release >> >> OK, in this case, no need to dma_release from rte_dma_pmd_release, >> because it is already called from rte_dma_close. > > Ping for reply please. Sorry, I think the previous reply was enough, Let me explain: The PMD use following logic create dmadev: skeldma_probe \-> skeldma_create \-> rte_dma_pmd_allocate \-> dma_allocate \-> mark dmadev state to READY. The PMD remove will be: skeldma_remove \-> skeldma_destroy \-> rte_dma_pmd_release \-> rte_dma_close \-> dma_release The application close dmadev: rte_dma_close \-> dma_release in the above case, the PMD remove and application close both call rte_dma_close, I think that's what you expect. skeldma is simple, please let me give you a complicated example: hisi_dma_probe \-> hisi_dma_create \-> rte_dma_pmd_allocate \-> dma_allocate \-> hisi_hw_init \-> if init fail, call rte_dma_pmd_release. \-> dma_release \-> if init OK, mark dmadev state to READY. as you can see, if hisi_hw_init fail, it call rte_dma_pmd_release to release dmadev, it will direct call dma_release. if hisi_hw_init success, it mean the hardware also OK, then mark dmadev state to READY. if PMD remove the dmadev it will call rte_dma_close because the dmadev's state is READY, and the application could also call rte_dma_close to destroy dmadev. The rte_dma_pmd_release take two function: 1. if the dmadev's hardware part init fail, the PMD could use this function release the dmadev. 2. if the dmadev's hardware part init success, the PMD could use this function destroy the dmadev. If we don't have the rte_dma_pmd_release function, we should export dma_release function which invoked when the hardware init fail. And if we keep rte_dma_pmd_release, it correspond the rte_dma_pmd_allocate, the PMD just invoke rte_dma_pmd_release to handle above both cases (hardware part init fail when probe and remove phase). Thanks. > > > > > . >