From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-f170.google.com (mail-ua0-f170.google.com [209.85.217.170]) by dpdk.org (Postfix) with ESMTP id 2C3799E3 for ; Tue, 7 Feb 2017 16:55:45 +0100 (CET) Received: by mail-ua0-f170.google.com with SMTP id y9so87964229uae.2 for ; Tue, 07 Feb 2017 07:55:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eGXQpnsWWBgED7jtUaPpVVsg1629m58OBUbg3EbLaCI=; b=LS94EDEbm/q4+MUsnjcwn2qUMZ7UmjEWk/vgRpsOvXHRtppEV5ATKWZp1pboM/JohC X8qx8PTZAsvUjQ/HDJ62OHsSjcMfWj9nr39v8OHhHYh8Pe/8CSBQqaoEqB8EHptpSjWm sAavuwn7VpgoBSd99K1o8Nv6OU29ln94PMfZwfOYJSTEbbO/3TQxDIpJ+Plh3dTDz80t JG3hILbkowWxjdITXDL+0IrmTnytcV5ElTd59QUkj2jLSmPkCX4t+duXwlMK5OG4im0Y HhLBpLB5WG7OoAonIqLUkoaDXF5W1x8ZFWFyU3oEQ6CHhRGc8bMehDpQAcrGsYUmYDBp 2M3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eGXQpnsWWBgED7jtUaPpVVsg1629m58OBUbg3EbLaCI=; b=QkBa4lqRwhV/Sd310ePfmAWbw8g16B7G4lz0jFV6nb162YxJ5OI1yIrG2eUljICAHH mYVHCq5zufGkf9D/4tVvXb9rJnIcaNjNQdrRyCNSF5ur/IXtoqysf6Jt2clGKi1YoA1T +0lPp+xPPHwsDddYO/CbJgBgBAMVkG6wVpa8cIG3E6cfDDYwtV5S34+BSsoikDeT+MFJ I2L+ZW4/HhHZRLcYt7xrp20L2q0aCspdDX/Jbky5aCSNoWMHSMDL8dLYRhpnQb9fIGj6 B6mBOP1DS7VyPdrNweQHGa9m0QOri2aOcgofZI3pRcTxbqzQgKp9sj/WH3w5+3BWYf6P 5fxg== X-Gm-Message-State: AMke39nzRlflCSp0yj+YRXVvUtdeC1KJRPYwKRvB/42Ok9qJkeDI0vqdH1xtmjFkdQ41siNP1HNlpl2IVFIB7g== X-Received: by 10.176.83.218 with SMTP id l26mr6807135uaa.69.1486482944382; Tue, 07 Feb 2017 07:55:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.136.7 with HTTP; Tue, 7 Feb 2017 07:55:43 -0800 (PST) In-Reply-To: <20170207095304.24e13480@glumotte.dev.6wind.com> References: <790E2AC11206AC46B8F4BB82078E34F8062736DF@EXUSMBX02.AD.MLP.com> <20170206145105.6a9016ec@platinum> <20170207095304.24e13480@glumotte.dev.6wind.com> From: Pavel Shirshov Date: Tue, 7 Feb 2017 07:55:43 -0800 Message-ID: To: Olivier MATZ Cc: vlad.lazarenko@worldquant.com, users@dpdk.org Content-Type: text/plain; charset=UTF-8 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 15:55:45 -0000 Hi Olivier, I got your point. Thank you for explaining. My point is about following. DPDK is not so traditional library. This library is used for high performance applications, when every detail is important. Your initial answer with details how mempool is implemented showed some DPDK internal details. Which was very valuable for me. I'm reading dpdk-users to get this kind of internal information about DPDK, because DPDK has a good documentation, but not comprehensive one. dpdk-users gives much more valuable information, than DPDK documentation itself. Thanks On Tue, Feb 7, 2017 at 12:53 AM, Olivier MATZ wrote: > 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