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 3F10B316B; Mon, 1 Apr 2019 09:30:45 +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 041FB280064; Mon, 1 Apr 2019 07:30:43 +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; Mon, 1 Apr 2019 08:30:37 +0100 To: Pavan Nikhilesh Bhagavatula , "Jerin Jacob Kollanukkaran" , "thomas@monjalon.net" , "ferruh.yigit@intel.com" , "stephen@networkplumber.org" CC: "dev@dpdk.org" , "stable@dpdk.org" References: <20190331162437.13048-1-pbhagavatula@marvell.com> From: Andrew Rybchenko Message-ID: <105f221f-0c64-e950-df9a-2c9eaa0991c3@solarflare.com> Date: Mon, 1 Apr 2019 10:30:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190331162437.13048-1-pbhagavatula@marvell.com> 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-24524.003 X-TM-AS-Result: No-17.182800-8.000000-10 X-TMASE-MatchedRID: u7Yf2n7Ca/0OwH4pD14DsPHkpkyUphL9mz61vg1cgl58vx8dQICa63Z5 WvuLBD7qt4mrRKhpAWz2/GgebwVtjNB/8y3gYF9vbCMnhMV5TW4NNaoo736rU+IpRqgiF5rt95r i4fhj2G8hXi7xgp14qyf0P3B4TwJKifsNgXDdrIa628cXbnOhTwkN8Uvsy+nthmigT1Q2zjTzTu 35URal5iBkhyrvdMSlklPOPDP4bOjHuFqMm/pFRcg6fo0rxLVrJd2n2XoSRFnnZVNiuSZvW4IAQ LFFublkZpnOW1F7m/Ip4656j5bjlKTCGfFuDW355BgEdUqqANR9LQinZ4QefL6qvLNjDYTwsuf7 RWbvUtxjYGxdKEQ2dLUQolgBkUgI1/VJumOv7m6eezCXllwSyqZ2zx2EEKsS0QdgugIAxC3v/DA n0oEiRtVWDe3Gwo7POhEHAMLCJrEXnVU97WUGenRBpzOiZFyT X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--17.182800-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24524.003 X-MDID: 1554103844-sfPQFg_Ni2sy 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] ethdev: fix DMA zone reserve not honoring size 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: Mon, 01 Apr 2019 07:30:45 -0000 On 3/31/19 7:25 PM, Pavan Nikhilesh Bhagavatula wrote: > From: Pavan Nikhilesh > > The `rte_eth_dma_zone_reserve()` is generally used to create HW rings. > In some scenarios when a driver needs to reconfigure the ring size > since the named memzone already exists it returns the previous memzone > without checking if a different sized ring is requested. > > Introduce a check to see if the ring size requested is different from the > previously created memzone length. > > Fixes: 719dbebceb81 ("xen: allow determining DOM0 at runtime") > Cc: stable@dpdk.org > > Signed-off-by: Pavan Nikhilesh > --- > lib/librte_ethdev/rte_ethdev.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c > index 12b66b68c..4ae12e43b 100644 > --- a/lib/librte_ethdev/rte_ethdev.c > +++ b/lib/librte_ethdev/rte_ethdev.c > @@ -3604,9 +3604,12 @@ rte_eth_dma_zone_reserve(const struct rte_eth_dev *dev, const char *ring_name, > } > > mz = rte_memzone_lookup(z_name); > - if (mz) > + if (mz && (mz->len == size)) > return mz; > > + if (mz) > + rte_memzone_free(mz); NACK I really don't like that API which should reserve does free if requested size does not match previously allocated. I understand the motivation, but I don't think the solution is correct. > + > return rte_memzone_reserve_aligned(z_name, size, socket_id, > RTE_MEMZONE_IOVA_CONTIG, align); > } 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 4FE47A068B for ; Mon, 1 Apr 2019 09:30:49 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 28FC64C90; Mon, 1 Apr 2019 09:30:47 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 3F10B316B; Mon, 1 Apr 2019 09:30:45 +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 041FB280064; Mon, 1 Apr 2019 07:30:43 +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; Mon, 1 Apr 2019 08:30:37 +0100 To: Pavan Nikhilesh Bhagavatula , "Jerin Jacob Kollanukkaran" , "thomas@monjalon.net" , "ferruh.yigit@intel.com" , "stephen@networkplumber.org" CC: "dev@dpdk.org" , "stable@dpdk.org" References: <20190331162437.13048-1-pbhagavatula@marvell.com> From: Andrew Rybchenko Message-ID: <105f221f-0c64-e950-df9a-2c9eaa0991c3@solarflare.com> Date: Mon, 1 Apr 2019 10:30:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190331162437.13048-1-pbhagavatula@marvell.com> 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-24524.003 X-TM-AS-Result: No-17.182800-8.000000-10 X-TMASE-MatchedRID: u7Yf2n7Ca/0OwH4pD14DsPHkpkyUphL9mz61vg1cgl58vx8dQICa63Z5 WvuLBD7qt4mrRKhpAWz2/GgebwVtjNB/8y3gYF9vbCMnhMV5TW4NNaoo736rU+IpRqgiF5rt95r i4fhj2G8hXi7xgp14qyf0P3B4TwJKifsNgXDdrIa628cXbnOhTwkN8Uvsy+nthmigT1Q2zjTzTu 35URal5iBkhyrvdMSlklPOPDP4bOjHuFqMm/pFRcg6fo0rxLVrJd2n2XoSRFnnZVNiuSZvW4IAQ LFFublkZpnOW1F7m/Ip4656j5bjlKTCGfFuDW355BgEdUqqANR9LQinZ4QefL6qvLNjDYTwsuf7 RWbvUtxjYGxdKEQ2dLUQolgBkUgI1/VJumOv7m6eezCXllwSyqZ2zx2EEKsS0QdgugIAxC3v/DA n0oEiRtVWDe3Gwo7POhEHAMLCJrEXnVU97WUGenRBpzOiZFyT X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--17.182800-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24524.003 X-MDID: 1554103844-sfPQFg_Ni2sy 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] ethdev: fix DMA zone reserve not honoring size 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: <20190401073033.d8sKlRtJEnGp4jnNDWF86w7eUxC4VKJnN8n2m-EdX3g@z> On 3/31/19 7:25 PM, Pavan Nikhilesh Bhagavatula wrote: > From: Pavan Nikhilesh > > The `rte_eth_dma_zone_reserve()` is generally used to create HW rings. > In some scenarios when a driver needs to reconfigure the ring size > since the named memzone already exists it returns the previous memzone > without checking if a different sized ring is requested. > > Introduce a check to see if the ring size requested is different from the > previously created memzone length. > > Fixes: 719dbebceb81 ("xen: allow determining DOM0 at runtime") > Cc: stable@dpdk.org > > Signed-off-by: Pavan Nikhilesh > --- > lib/librte_ethdev/rte_ethdev.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c > index 12b66b68c..4ae12e43b 100644 > --- a/lib/librte_ethdev/rte_ethdev.c > +++ b/lib/librte_ethdev/rte_ethdev.c > @@ -3604,9 +3604,12 @@ rte_eth_dma_zone_reserve(const struct rte_eth_dev *dev, const char *ring_name, > } > > mz = rte_memzone_lookup(z_name); > - if (mz) > + if (mz && (mz->len == size)) > return mz; > > + if (mz) > + rte_memzone_free(mz); NACK I really don't like that API which should reserve does free if requested size does not match previously allocated. I understand the motivation, but I don't think the solution is correct. > + > return rte_memzone_reserve_aligned(z_name, size, socket_id, > RTE_MEMZONE_IOVA_CONTIG, align); > }