From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 71FFE5A31 for ; Thu, 21 Jul 2016 23:16:23 +0200 (CEST) Received: by mail-wm0-f42.google.com with SMTP id q128so35111141wma.1 for ; Thu, 21 Jul 2016 14:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=JLgPPl/tUT3xwN89uB0lYOI8TCGhuLs5qm9W4zZq844=; b=Uh2q9i1xvGc6vuqv71F2LvwkhaDVTFSEAFZqJtEwx6QrO6nXeRbnjyZ9ebP+jc4K8w q3+BZG6E1tgvBNgCsckLUrXNCI2QV/oaXpp9Kw23DpMk4UFgsLlPDspuya0K3t/Dqc0/ BUto07PRZM8KmcBKuplFFWmX5cj/sKhh8IR+DEtCzv7B8MKWQLIJ57OyMEojHb4+GRJ6 /fA/ZBvflE0HaqR5jiJm+6KC6MVN71OStaxJ2br+xJxDN1qpzasoYu4WY2LvJgJjHdTM 4yak282wPAQOPO/6cKf8HXz2YowajnqlXGJIf+8B20wRon6wz4B/RbhCLaIEzrAnwmRp gFFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=JLgPPl/tUT3xwN89uB0lYOI8TCGhuLs5qm9W4zZq844=; b=ARPgWBsEUSXuHCrkNgp+BH4MXMeKdwhDpE2goCFTbePp9kSAg4FI/ZVsHY6zhUoV5E 9r5LD2l+bQeYt1ASrrKSI0C1xq41JRKf2JZy22OFQKm/5mO4idMY1K9UUXOOY5QL+xkM OJL70npdRKOicwpSMbmSqVUTN7aYiAiO6+Nb7J0etHElFSxWkQHiNpRSc55fJ9pI8ijU OILqEl3BlKbEkO2dd05Z42EkoWu76v+XrbskE66UjZnPw75iN6Gbafp+yu7fWUSW2Gh0 Qis2NuAeyHWc/co9NkaJHUJTLlyEW8BxpFy07oexYQBI2AEwpWYVVbjviTRkPp15YtiO ZTYw== X-Gm-Message-State: AEkooutD6FihrxjMAWSAfnLGVeUcI2CA2DqVlNVq7kNvA6BsTnTmRS/mDNXKCU6+RFBDoIKx X-Received: by 10.28.64.86 with SMTP id n83mr576003wma.52.1469135783230; Thu, 21 Jul 2016 14:16:23 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id x133sm7283314wmf.16.2016.07.21.14.16.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2016 14:16:22 -0700 (PDT) From: Thomas Monjalon To: Zoltan Kiss Cc: dev@dpdk.org, Olivier Matz , Zoltan Kiss , Bruce Richardson Date: Thu, 21 Jul 2016 23:16:21 +0200 Message-ID: <5162614.6uImdtqVO2@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <1e8aa5d1-b83e-5e35-e382-b0cc685ffb56@6wind.com> References: <1469034999-2732-1-git-send-email-zoltan.kiss@schaman.hu> <34eb5f3b-307a-3072-d262-e46a6437eea7@linaro.org> <1e8aa5d1-b83e-5e35-e382-b0cc685ffb56@6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 21:16:23 -0000 2016-07-21 16:25, Olivier Matz: > On 07/21/2016 03:47 PM, Zoltan Kiss wrote: > > On 21/07/16 14:40, Olivier Matz wrote: > >> 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! > > Ok, looks fair, thanks for the clarification. > > Acked-by: Olivier Matz Applied, thanks