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 C5E3E29D2 for ; Fri, 20 Jul 2018 17:49:48 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 28A1E780069; Fri, 20 Jul 2018 15:49:47 +0000 (UTC) Received: from [192.168.1.16] (85.187.13.33) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 20 Jul 2018 16:49:37 +0100 To: Pablo de Lara , CC: References: <20180717103720.26783-1-pablo.de.lara.guarch@intel.com> From: Andrew Rybchenko Message-ID: <6a46bfe4-c016-dacc-74d4-5e61a161fced@solarflare.com> Date: Fri, 20 Jul 2018 18:49:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180717103720.26783-1-pablo.de.lara.guarch@intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [85.187.13.33] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23980.003 X-TM-AS-Result: No--7.880900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1532101787-CSL7ScdlahuD Subject: Re: [dpdk-dev] [PATCH] mempool: check for invalid args on creation 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, 20 Jul 2018 15:49:49 -0000 On 17.07.2018 13:37, Pablo de Lara wrote: > Currently, a mempool can be created if the number of > objects is zero or the size of these is zero. > In these scenarios, rte_mempool_create should return NULL, > as the mempool created is useless. > > Signed-off-by: Pablo de Lara > --- > lib/librte_mempool/rte_mempool.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c > index 8c8b9f809..8c9573f1a 100644 > --- a/lib/librte_mempool/rte_mempool.c > +++ b/lib/librte_mempool/rte_mempool.c > @@ -916,6 +916,18 @@ rte_mempool_create_empty(const char *name, unsigned n, unsigned elt_size, > > mempool_list = RTE_TAILQ_CAST(rte_mempool_tailq.head, rte_mempool_list); > > + /* asked for zero items */ > + if (n == 0) { > + rte_errno = EINVAL; > + return NULL; > + } I agree which the check since attempt to populate it will most likely fail with -ENOSPC. > + > + /* asked for zero-sized elements */ > + if (elt_size == 0) { > + rte_errno = EINVAL; > + return NULL; > + } > + I'm not sure about this one. I could imagine the case when mempool elements are used just as unique markers. So, I'm not sure that we should restrict such usage. > /* asked cache too big */ > if (cache_size > RTE_MEMPOOL_CACHE_MAX_SIZE || > CALC_CACHE_FLUSHTHRESH(cache_size) > n) {