From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 7C514A0096 for ; Wed, 8 May 2019 15:52:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 979EF2C2B; Wed, 8 May 2019 15:52:38 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 5C3732B87 for ; Wed, 8 May 2019 15:52:36 +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 ED62A80007C; Wed, 8 May 2019 13:52: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; Wed, 8 May 2019 14:52:27 +0100 To: David Marchand , wangyunjian , Thomas Monjalon , "Yigit, Ferruh" CC: dev , References: <1556358462-9920-1-git-send-email-wangyunjian@huawei.com> From: Andrew Rybchenko Message-ID: Date: Wed, 8 May 2019 16:52:22 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: 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-24598.003 X-TM-AS-Result: No-13.515300-8.000000-10 X-TMASE-MatchedRID: 8+bhjh9TQnF2LasmHuCXMSa1MaKuob8PC/ExpXrHizwXdhT0BAdFzlDy /dQ7+3TiCEnJT1I79jB8SCKVahhnrJsYdIGP6PlZbc297PAGtWYrHkgIan9a0XH6hAZFGcMQT85 +SH/4Avjlc+ZUX/8YDEqtq4hv0xE/BrU1duOq6zQdxBAG5/hkW7qGBW9J0YqjwEz5jkq73mWRnE JOP6CIAo2jjJThmO3h4YS6FyG8vyjyUQNiagGSs9sfxZpQv2qMm/y00tE9Sta/wz3p7pLVvSxZV 2XdhwOw7fNKgmEEsE040yU8mjuEx62HRIS8LpzUiguiJuCNURcytf6nW43O0HqI+ZX9vDCC3SlE gVuyN9tvuYnoduGWEV+24nCsUSFN+dkjd91LgACx5amWK2anSLVV9mtf2bFYLXCOiuJqm98OWwB STaiEbyWDGlj+FN10lMyZQApvmb38QRMpEr4RHrzpouUpE4wZWe2eEDKzv5s4slxutWUZcu+3mA tH4obY X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--13.515300-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24598.003 X-MDID: 1557323555-122r0oqphXMb 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] ethdev: add size and align to compose dma zone name strings 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190508135222.jh0A0ASC_hsTANYLF-yrupnaXmDGecRRC7RQPB8king@z> On 4/29/19 11:03 AM, David Marchand wrote: > On Sat, Apr 27, 2019 at 11:48 AM wangyunjian > wrote: > > From: Yunjian Wang > > > The current dma zone name consists of the port_id, queue_id and > ring_name. If a port_id is reused, a new nic maybe use same dma > zone name. At this time, the zone size of the new driver is > differnt. When the zone is reused, it may cause illegal access > to memory. > > Signed-off-by: Yunjian Wang > > --- >  lib/librte_ethdev/rte_ethdev.c | 6 +++--- >  1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/lib/librte_ethdev/rte_ethdev.c > b/lib/librte_ethdev/rte_ethdev.c > index d7cfa3d..0703cda 100644 > --- a/lib/librte_ethdev/rte_ethdev.c > +++ b/lib/librte_ethdev/rte_ethdev.c > @@ -3630,9 +3630,9 @@ int rte_eth_set_queue_rate_limit(uint16_t > port_id, uint16_t queue_idx, >         const struct rte_memzone *mz; >         int rc; > > -       rc = snprintf(z_name, sizeof(z_name), "eth_p%d_q%d_%s", > -                     dev->data->port_id, queue_id, ring_name); > -       if (rc >= RTE_MEMZONE_NAMESIZE) { > +       rc = snprintf(z_name, sizeof(z_name), "p%dq%d%s0x%zx_%d", > +                     dev->data->port_id, queue_id, ring_name, > size, align); > +       if (rc >= RTE_MEMZONE_NAMESIZE || rc < 0) { >                 RTE_ETHDEV_LOG(ERR, "ring name too long\n"); >                 rte_errno = ENAMETOOLONG; >                 return NULL; > > > In such a case, we are leaving the previous memzone in place and just > creating a new one. > Should the driver free the previous memzone instead? > > I can't see this in existing drivers. > Do we actually expect to reuse the existing memzones? > I don't think the patch is a right way to go. It is related to [1] which has a long discussion. Andrew. [1] https://patches.dpdk.org/patch/51952/