From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 65C271B158 for ; Fri, 12 Oct 2018 09:54:51 +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-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id C3D94800059; Fri, 12 Oct 2018 07:54:44 +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 08:54:37 +0100 To: Thomas Monjalon , CC: , , , , "Ananyev, Konstantin" , Ajit Khaparde , Somnath Kotur , Rahul Lakkireddy References: <20180907230958.21402-1-thomas@monjalon.net> <20181011210251.7705-1-thomas@monjalon.net> <20181011210251.7705-2-thomas@monjalon.net> From: Andrew Rybchenko Message-ID: Date: Fri, 12 Oct 2018 10:53:56 +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: <20181011210251.7705-2-thomas@monjalon.net> 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-13.481400-8.000000-10 X-TMASE-MatchedRID: QfHZjzml1E8OwH4pD14DsPHkpkyUphL9mz61vg1cgl6CsBeCv8CM/Zxz 8+1dXyV40A6NBT1QJ2pkBfBoO7jomct+2Xe+MgKzA9lly13c/gEK3n1SHen81WyovJz/KSE7Th3 PpSDQCcN1PZg9oWxRpTVsHAR6Tt8AsznIV04I19FoOA9kFf9sy+q9xwosX7inDC/Vm90If4VUza n9xEPKMWJz/nKtphYOV5samMezmZbGV1Io4ZdpfBkJVFT9oj3MLZWWNVgH0Y3ZhqPLU/1bVd0pR IFbsjfbb7mJ6HbhlhFftuJwrFEhTbew1twePJJBsjvNV98mpPP/SKgvt4YmWcFpOwfs/7miax/X Sh+R57wnrUDywuqo+jsKyA5uiZqdpmU8Ea0fr6+cwNwd/PEf+Wp/5r88S/yxhsh0ELBpP1c= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--13.481400-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24150.003 X-MDID: 1539330886-QnHIplBYOSek Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit 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 07:54:51 -0000 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)  - drivers/net/bnx2x/bnx2x_rxtx.c  - drivers/net/cxgbe/sge.c (few times) I've not dig why bnx2x and cxgbe do not use rte_eth_dma_zone_reserve().