From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com [209.85.215.51]) by dpdk.org (Postfix) with ESMTP id BF4162C69 for ; Tue, 19 Jul 2016 17:59:30 +0200 (CEST) Received: by mail-lf0-f51.google.com with SMTP id g62so18318200lfe.3 for ; Tue, 19 Jul 2016 08:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=GKgiHkqR5AAa35eIdmSPS6wHYL78Vc1DzsFz98xAZDY=; b=fQq0ro4EJTzGGK9fOpjI8EUqsRRbcvsQ/E5gSE2SyyQqqTdHY5QFXqzyq8SvcC7R6u BQHMsnBJQjhiXAmXdseRpbQhB92khCimXk4N5+UN67W8cLypTqUyGZoMcZNHKK+IrTE2 MyYD+n4kslZpcr/lPscbS/khxGyxX8O6kYreo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GKgiHkqR5AAa35eIdmSPS6wHYL78Vc1DzsFz98xAZDY=; b=F1CjQWOFSaPn5x0Lv6Z4/q+L+m2F2tRVW3H9oJ8XmBQrtpGrRJGhHiBMd7+9mLKn+4 tPnIatXcupB2L0tnVJYD42Spi8YnbEIP8yw+3MjihPvMT1LBCu5SmrGwBQPpbc/EozKv hx9nZ2WxR1ZHidwY3Xi6tGb886GwFLAuHzFG4ZIfVsYk+eW+g+F4FrZLs1TNposneD/6 bAKFJOn5f0IRG36lBj/n86Ixct6doLGsnO1gCsTawcvfO2B/7kUtIw9DDvo7U2tWnfXA H4FGdrq9vDK9ZBLF8gJvl0Rx1K/zt12TYQC/kpDWNXCTAseD3+EjHoyp4VwrB0Fl4IIv JrpQ== X-Gm-Message-State: ALyK8tKR0Hg366zavRHam5liHIeENPYqU2gp/M/odM6/InWhmWV4PFx7iMXJ2xezC1BfaJZU X-Received: by 10.25.19.96 with SMTP id j93mr18534512lfi.13.1468943970021; Tue, 19 Jul 2016 08:59:30 -0700 (PDT) Received: from [172.18.45.108] ([195.11.233.227]) by smtp.googlemail.com with ESMTPSA id 136sm4129582ljj.0.2016.07.19.08.59.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 08:59:29 -0700 (PDT) To: Olivier Matz , 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> From: Zoltan Kiss Message-ID: <578E4E60.80802@linaro.org> Date: Tue, 19 Jul 2016 16:59:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <600cac7d-b0aa-7919-93f2-7a396ef7b3ea@6wind.com> Content-Type: text/plain; charset=windows-1252; format=flowed 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 15:59:31 -0000 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. 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. > > 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. > > In any case, I think it's a bit late for 16.07 for this kind of fix. > > Regards, > Olivier >