From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 256AF1BACA for ; Fri, 12 Oct 2018 18:43:35 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 835C0400070; Fri, 12 Oct 2018 16:43:33 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 12 Oct 2018 17:43:26 +0100 To: Thomas Monjalon CC: , , , , , "Ananyev, Konstantin" , Ajit Khaparde , Somnath Kotur , Rahul Lakkireddy References: <20180907230958.21402-1-thomas@monjalon.net> <20181011210251.7705-2-thomas@monjalon.net> <3669676.Ndm0HoEbJM@xps> From: Andrew Rybchenko Message-ID: <82229acf-1ade-6056-7aaf-d05ffead0792@solarflare.com> Date: Fri, 12 Oct 2018 19:42:44 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <3669676.Ndm0HoEbJM@xps> Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24150.003 X-TM-AS-Result: No-14.636900-8.000000-10 X-TMASE-MatchedRID: 6otD/cJAac0OwH4pD14DsPHkpkyUphL9mz61vg1cgl6CsBeCv8CM/Zxz 8+1dXyV40A6NBT1QJ2pkBfBoO7jomct+2Xe+MgKzA9lly13c/gEK3n1SHen81WyovJz/KSE7Th3 PpSDQCcN1PZg9oWxRpTVsHAR6Tt8A06P6nK44odB0CDjJ3XioBMnlJe2gk8vIBlt4RZwvTdV3Uo 1OB3WVq78hxCtjovyY4YS6FyG8vyjyUQNiagGSs9sfxZpQv2qMm/y00tE9Sta/wz3p7pLVvSxZV 2XdhwOw7fNKgmEEsE1qlnm6jwp3Dzhzk989ZlO2BxsweNg3EaGFkCkkB0UMNpsoi2XrUn/JyeMt MD9QOgChMIDkR/KfwCIQ5mZ5SqHPTKBBoAGLVPtBKarCugy2zEJo6Q+dRTrZq4Mk1ThN7TmobaH 2dbrHa+QZ9pw2286sVtyf7eR+XXJholiU3Qq7ng3oXQHWSu9qSwwcGKLTYEc= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--14.636900-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24150.003 X-MDID: 1539362614-S8oV3dNcybts Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: rename memzones allocated for DMA X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 16:43:35 -0000 On 10/12/18 7:40 PM, Thomas Monjalon wrote: > 12/10/2018 09:53, Andrew Rybchenko: >> On 10/12/18 12:02 AM, Thomas Monjalon wrote: >>> The helper rte_eth_dma_zone_reserve() is called by PMDs >>> when probing a new port. >>> It creates a new memzone with an unique name. >>> The name of this memzone was using the name of the driver >>> doing the probe. >>> >>> In order to avoid assigning the driver before the end of the probing >>> (next patch), the driver name is removed from these memzone names. >>> The ethdev name (data->name) is not used because it may be too long >>> and may be not set at this stage of probing. >>> >>> Syntax of old name: ___ >>> Syntax of new name: eth_p_q_ >>> >>> Signed-off-by: Thomas Monjalon >>> --- >>> lib/librte_ethdev/rte_ethdev.c | 5 ++--- >>> 1 file changed, 2 insertions(+), 3 deletions(-) >>> >>> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c >>> index ef99f7068..ec443def5 100644 >>> --- a/lib/librte_ethdev/rte_ethdev.c >>> +++ b/lib/librte_ethdev/rte_ethdev.c >>> @@ -3441,9 +3441,8 @@ rte_eth_dma_zone_reserve(const struct rte_eth_dev *dev, const char *ring_name, >>> char z_name[RTE_MEMZONE_NAMESIZE]; >>> const struct rte_memzone *mz; >>> >>> - snprintf(z_name, sizeof(z_name), "%s_%s_%d_%d", >>> - dev->device->driver->name, ring_name, >>> - dev->data->port_id, queue_id); >>> + snprintf(z_name, sizeof(z_name), "eth_p%d_q%d_%s", >>> + dev->data->port_id, queue_id, ring_name); >>> >>> mz = rte_memzone_lookup(z_name); >>> if (mz) >> LGTM, but I've found more places where the pattern is duplicate >> and testpmd frightens me: >> - app/test-pmd/config.c ring_dma_zone_lookup() which is used >> to look at descriptors (looks like Intel specific since has >> RTE_LIBRTE_I40E_16BYTE_RX_DESC conditional code) > >From what I see there is no access to rte_device.driver here, > except one in exit function. Yes, but testpmd will fail to find the memzone and command to take a look at descriptors will be broken. May be it is already broken etc. I think someone from Intel should comment it.