From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) by dpdk.org (Postfix) with ESMTP id 03BB347D1 for ; Thu, 21 Jul 2016 15:47:51 +0200 (CEST) Received: by mail-lf0-f50.google.com with SMTP id g62so62431224lfe.3 for ; Thu, 21 Jul 2016 06:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=xKmqaa7XMecd8iQEa7uH0Rb5qnjFulQVQ/XqSN4nwEQ=; b=VHZrdEUmySma4B84kb0nSP+oz0ixdRw1cYo14o9fuVnB7RC7etMSBe775ZsIwUnR0+ RW8UWWwDg6L1WDAy/UdcgEXfGkaEbQzKxjwBy6Z3LIh4Y6gZs3SQg/fbk7GRmx+ItqKw Yx2ftQjxnKQIz9AvB+x24H8/S150wB8YTDFSU= 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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=xKmqaa7XMecd8iQEa7uH0Rb5qnjFulQVQ/XqSN4nwEQ=; b=Hyvi725M+1c3yBXiPNZiL/7lDe4YNv9zJnDZzY5FpP79ZtMIqq+Nl3VQqK7AcZemGe F1c+siyJbuNdxmsLL4iylq+hFgyM1L4h8HxxyyKa8OtuhCX2tLTjTLGgzWFkEBUEkzWq qKJJP3mYr903M69QX3TwsmX+Olyq6/F9C4+dS28PS6KEHK0NXyOBp5TkihOo90ptvTUt YDDLo1rj/eVKE8bz32cVu2eWAmXCglMyBS13VZ/SEGZROG3agSSGl8eg61ccKjCtD6jF FAtH4le/KCXOlwLx6Kzz94YD6KSmZSOYriI/pyPDI8UETwePDcZX5ZRbKKWH970nSELf lGEA== X-Gm-Message-State: ALyK8tKlOVUOeEApQy5N+yQrYmji4fLzQwC782QK1M+vWuQ3eGE2wCDMHrQMIDd25m9peYsl X-Received: by 10.25.83.85 with SMTP id h82mr9744544lfb.97.1469108869566; Thu, 21 Jul 2016 06:47:49 -0700 (PDT) Received: from [172.18.45.108] ([195.11.233.227]) by smtp.googlemail.com with ESMTPSA id 90sm1841943lfw.30.2016.07.21.06.47.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2016 06:47:48 -0700 (PDT) To: Olivier Matz , Zoltan Kiss , dev@dpdk.org References: <1469034999-2732-1-git-send-email-zoltan.kiss@schaman.hu> Cc: Bruce Richardson From: Zoltan Kiss Message-ID: <34eb5f3b-307a-3072-d262-e46a6437eea7@linaro.org> Date: Thu, 21 Jul 2016 14:47:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] 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: Thu, 21 Jul 2016 13:47:51 -0000 On 21/07/16 14:40, Olivier Matz wrote: > Hi Zoltan, > > > On 07/20/2016 07:16 PM, Zoltan Kiss wrote: >> A recent patch brought up an issue about the size of the 'name' fields: >> >> 85cf0079 mem: avoid memzone/mempool/ring name truncation >> >> These relations should be observed: >> >> 1. Each ring creates a memzone with a prefixed name: >> RTE_RING_NAMESIZE <= RTE_MEMZONE_NAMESIZE - strlen(RTE_RING_MZ_PREFIX) >> >> 2. There are some mempool handlers which create a ring with a prefixed >> name: >> RTE_MEMPOOL_NAMESIZE <= RTE_RING_NAMESIZE - strlen(RTE_MEMPOOL_MZ_PREFIX) >> >> 3. A mempool can create up to RTE_MAX_MEMZONE pre and postfixed memzones: >> sprintf(postfix, "_%d", RTE_MAX_MEMZONE) >> RTE_MEMPOOL_NAMESIZE <= RTE_MEMZONE_NAMESIZE - >> strlen(RTE_MEMPOOL_MZ_PREFIX) - strlen(postfix) >> >> Setting all of them to 32 hides this restriction from the application. >> This patch decreases the mempool and ring string size to accommodate for >> these prefixes, but it doesn't apply the 3rd constraint. Applications >> relying on these constants need to be recompiled, otherwise they'll run >> into ENAMETOOLONG issues. >> The size of the arrays are kept 32 for ABI compatibility, it can be >> decreased next time the ABI changes. >> >> Signed-off-by: Zoltan Kiss > > Looks like to be a good compromise for the 16.07 release. One question > however: why not taking in account the 3rd constraint? Because it may > not completly fix the issue if the mempool is fragmented. > > We could define RTE_MEMPOOL_NAMESIZE to 24 > = 32 - len('mp_') - len('_0123')) I was trying to figure out a compile time macro for strlen(postfix), but I could not. Your suggestion would work only until someone increases RTE_MAX_MEMZONE above 9999. As the likelihood of fragmenting a pool over 99 memzones seems small, I did not bother to fix this with an ugly hack, but if you think we should include it, let me know! > > Thanks, > Olivier >