From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f171.google.com (mail-wr0-f171.google.com [209.85.128.171]) by dpdk.org (Postfix) with ESMTP id 04421FFA for ; Tue, 7 Feb 2017 09:53:13 +0100 (CET) Received: by mail-wr0-f171.google.com with SMTP id i10so36202831wrb.0 for ; Tue, 07 Feb 2017 00:53:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=YWZ/chWFjR22288VLpcKCDJ4C6cXWQOo5R/fd80ydiQ=; b=LHtLCtn0jRHb4l74royRFSU0u/j7Tpx+Z1A/MLTTujjhNmH7PFeZaXljxnCm23wu9j rNLqCVHwLMZHHhOMCddftwwAXMbnxq49W+2+L1SBFunzuQlKXruzAJc9tG5awC/lK5nZ +u+7qMlX9xaLR5L3jQqw+hNefXZZ4SGQc387i7zr9CR6o5VhjT3EoZ4R/CN+qjDy7cKA WOAuzPKFwR3td38xm98RE5qYQJvvI0RFC2J79pTrUgRNQRFDh3X5cCU4t7O4JH5wxH+w PgKMUQpI5ho6KpRfjaKO1WYjfbv6VwUNbSKhfKaBhrDC2LATtJ5e1puW7bgDw+rPx7B/ JmJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=YWZ/chWFjR22288VLpcKCDJ4C6cXWQOo5R/fd80ydiQ=; b=K0jQURov15H/f9pDNOqb/x2NSZmMmuSNmW6LsIRpRDv35DnafWfBzd9A107mUPqtCh bmeRXXlwlcBOoL7rASnSH4EcGgtaRiC+ME11SXoeeXyuH4u0/YVaLVBWvsP214OoYOCA 8HlBpnAmTrpwYhIogQoQNcsoVvxvSo2bgKfaysUcpEN6MD0d+HZy+po+5oT1Oa86Tt9f Upw3nCZCElcbxF/Tt6u0J8boLci+MwQ+/Yf/5iqii4UVBUL7ij0tdTV+dSopazF8N3np nbX+vrSWJe+P+XwOs7x4ec+rUfW/+m7CsPxBmKqjR4mlCtYyx7M6wM/cOm0gY//0qzr9 +DjA== X-Gm-Message-State: AIkVDXLrs9C6Cl0ajo1MsDeYD+z1EbaVsxLixirHjPOtl0neNDVIXC3AKw07BKwO24tFWs/f X-Received: by 10.223.161.222 with SMTP id v30mr14678986wrv.114.1486457592745; Tue, 07 Feb 2017 00:53:12 -0800 (PST) Received: from glumotte.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id 123sm17560233wml.6.2017.02.07.00.53.12 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 07 Feb 2017 00:53:12 -0800 (PST) From: Olivier MATZ X-Google-Original-From: Olivier MATZ Date: Tue, 7 Feb 2017 09:53:04 +0100 To: Pavel Shirshov Cc: Olivier Matz , vlad.lazarenko@worldquant.com, users@dpdk.org Message-ID: <20170207095304.24e13480@glumotte.dev.6wind.com> In-Reply-To: References: <790E2AC11206AC46B8F4BB82078E34F8062736DF@EXUSMBX02.AD.MLP.com> <20170206145105.6a9016ec@platinum> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-users] Optimal number of elements in mempool n = (2^q - 1) vs examples, what is the right thing to do? X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 08:53:13 -0000 Hi Pavel, On Mon, 6 Feb 2017 13:07:35 -0800, Pavel Shirshov wrote: > On Mon, Feb 6, 2017 at 5:51 AM, Olivier Matz > wrote: > > Hi Vlad, > > > > On Wed, 1 Feb 2017 16:54:57 +0000, Vlad.Lazarenko at worldquant.com > > (Lazarenko, Vlad (WorldQuant)) wrote: > >> Hello, > >> > >> I'm new to DPDK and have noticed that documentation for > >> rte_mempool_create states that the optimal size for a number of > >> elements in the pool is n = (2^q-1). But in many examples it is > >> simply set to 2^q (multi_process/simple_mp/main.c uses 2014, for > >> example). This is a bit confusing. Is 2^q - 1 really the optimal > >> number but examples don't use it, or maybe the documentation for > >> the mempool is wrong, or...? If anyone could shed some light on > >> this that'd be helpful. > > > > That's true for rte_mempool based on a rte_ring (this is the > > default, but since recently, it's possible to use another handler). > > > > The size of a rte_ring is (2^n - 1), because one element in the > > ring is reserved to distinguish between a full an an empty ring. > > So, when a mempool uses a ring, if we ask for 2^n elements, a ring > > of size (2^(n+1) - 1) is created, which can consume additional > > memory. > > > > On the other hand, the mempool object size is often much larger than > > a ring entry (usually 8 bytes, the size of a pointer), especially > > knowing that by default, the objects are cache aligned (usually 64 > > bytes). > > > > So we may remove this note in the future since it's not very > > relevant. > > Hi Olivier, > > It's a good explanation of rte_mempool internals. I think it would be > good to have your comment in the rte_mempool documentation. Could we > add it there? My comment applies on mempool based on rings (default), but it becomes wrong when using another handler (ex: stack, or upcoming hw handlers). Moreover, the size of the pointer array in ring is often negligible in comparison with the size of the objects array in mempool, making this comment no so useful. So I'll probably remove this part from API guide to the programmer's guide. Regards, Olivier