From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id BF9343B5 for ; Tue, 19 Jul 2016 18:17:39 +0200 (CEST) Received: from alille-653-1-293-182.w90-1.abo.wanadoo.fr ([90.1.53.182] helo=[192.168.1.13]) by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bPXkk-00050Q-RT; Tue, 19 Jul 2016 18:20:15 +0200 To: Zoltan Kiss , Zoltan Kiss , dev@dpdk.org References: <1468939061-19734-1-git-send-email-zoltan.kiss@schaman.hu> <1468939061-19734-2-git-send-email-zoltan.kiss@schaman.hu> <600cac7d-b0aa-7919-93f2-7a396ef7b3ea@6wind.com> <578E4E60.80802@linaro.org> From: Olivier Matz Message-ID: <85d13abf-b05e-67f0-16fd-3279cb4064be@6wind.com> Date: Tue, 19 Jul 2016 18:17:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <578E4E60.80802@linaro.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] mempool: adjust name string size in related data types X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:17:39 -0000 Hi Zoltan, On 07/19/2016 05:59 PM, Zoltan Kiss wrote: > > > On 19/07/16 16:37, Olivier Matz wrote: >> Hi Zoltan, >> >> On 07/19/2016 04:37 PM, Zoltan Kiss wrote: >>> A recent fix brought up an issue about the size of the 'name' fields: >>> >>> 85cf0079 mem: avoid memzone/mempool/ring name truncation >>> >>> These relations should be observed: >>> >>> RTE_RING_NAMESIZE <= RTE_MEMZONE_NAMESIZE - strlen(RTE_RING_MZ_PREFIX) >>> RTE_MEMPOOL_NAMESIZE <= RTE_RING_NAMESIZE - >>> strlen(RTE_MEMPOOL_MZ_PREFIX) >>> >>> Setting all of them to 32 hides this restriction from the application. >>> This patch increases the memzone string size to accomodate for these >>> prefixes, and the same happens with the ring name string. The ABI >>> needs to >>> be broken to fix this API issue, this way doesn't break applications >>> previously not failing due to the truncating bug now fixed. >>> >>> Signed-off-by: Zoltan Kiss >> >> I agree it is a problem for an application because it cannot know what >> is the maximum name length. On the other hand, breaking the ABI for this >> looks a bit overkill. Maybe we could reduce RTE_MEMPOOL_NAMESIZE and >> RTE_RING_NAMESIZE instead of increasing RTE_MEMZONE_NAMESIZE? That way, >> we could keep the ABI as is. > > But that would break the ABI too, wouldn't it? Unless you keep the array > the same size (32 bytes) by using RTE_MEMZONE_NAMESIZE. Yes, that was the idea. > And even then, the API breaks anyway. There are applications - I have at > least some - which use all 32 bytes to store the name. Decrease that > would cause headache to change the naming scheme, because it's a 30 > character long id, and chopping the last few chars would cause name > collisions and annoying bugs. Before my patch (85cf0079), long names were silently truncated when mempool created its ring and/or memzones. Now, it returns an error. I'm not getting why changing the struct to something like below would break the API, since it would already return an error today. #define RTE_MEMPOOL_NAMESIZE \ (RTE_MEMZONE_NAMESIZE - sizeof(pool_prefix) - sizeof(ring prefix)) struct rte_mempool { union { char name[RTE_MEMPOOL_NAMESIZE]; char pad[32]; }; ... } Anyway, it may not be the proper solution since it supposes that a mempool includes a ring based on a memzone, which is not always true now with mempool handlers. >> It would even be better to get rid of this static char[] for the >> structure names and replace it by an allocated const char *. I didn't >> check it's feasible for memzones. What do you think? > > It would work too, but I don't think it would help a lot. We would still > need max sizes for the names. Storing them somewhere else won't help us > in this problem. Why should we have a maximum length for the names? Thanks, Olivier