From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0C0DFA04F1 for ; Mon, 13 Jan 2020 10:47:15 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D5A401D627; Mon, 13 Jan 2020 10:47:14 +0100 (CET) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id 5BC121D61E for ; Mon, 13 Jan 2020 10:47:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578908832; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=H0Ofq3vZfw5l3k3ywUDVa0OIL40/+0r2H4PhmGGQdLU=; b=IXWMcsBq2vMnLqj9mV4F5uA7zzlDtsYlBY37gLI22uHe2Y9ZrbvnVir8ZvqyjiwnzoznwW lQa1ZIBKZzagYLOs8ffdcDdhRqzIm633fce8pcyYc3zyOxCDmn3GQVF3Zp8Sx5Wmy68SEN 7+atsDCReOphIbE/EuLF8Veqj2u4csk= Received: from mail-vk1-f199.google.com (mail-vk1-f199.google.com [209.85.221.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-145-qZCvPp9INGuiTjXqahiUAA-1; Mon, 13 Jan 2020 04:47:09 -0500 Received: by mail-vk1-f199.google.com with SMTP id l4so4457556vkn.2 for ; Mon, 13 Jan 2020 01:47:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A1REkfkQvDFAOEbZqkZNBpYGWci4Hrjs02/eOhPDAtg=; b=coZebB4lun9VV3wV1iunA9rU8LtKqwkdRj/woJz7n0J0UBTaNE9hVpRGclrn3MBhkD jdF4sDlnJgZuBLFQ2WT2uMtb3Btj+zqXisvQEB52BAsE5hadlu9J1ilA3sU6ThIhoeYY AkBNj4lLZhiVPyTwpHr1n1mMRrOBc7DCVOqNfLVsgpJg8he65NXkzI5fNGVcVmJZhgvV TfD0Y5a25BK+gQwfwwAvLANkXtk0rOGRNX2oJAE+oL5NOdDBctrY8EHk4c/mMWYDWO8F HBZI7o25bDgjimwNJPGxSgLam3Og+s48TFkx48XIyGnOfQniiddd0vuWUulQ8B74t7hf Qokg== X-Gm-Message-State: APjAAAVnV2fxHUcrPWEQulM42RHpHP+O61BFi016JhZbbTZFOwqI3LPn yF90PYaLE9vTlPZGYW0MAIeoAIoghRtUgjmz58s70/qPsLXqX25fT2RiLVL91DVDvIt1zoCOQq2 JmlQJ49eelVdVzhjhVvb8KaM= X-Received: by 2002:a67:f1ca:: with SMTP id v10mr5822125vsm.180.1578908826790; Mon, 13 Jan 2020 01:47:06 -0800 (PST) X-Google-Smtp-Source: APXvYqyXCVmIjMiPOiOH2rOWTYLle89kFPaR0WddUMsNoPK7C4ToyniNukgnggRQWDvsaLMjH29YrkNeE0dEThvMPVo= X-Received: by 2002:a67:f1ca:: with SMTP id v10mr5822104vsm.180.1578908826465; Mon, 13 Jan 2020 01:47:06 -0800 (PST) MIME-Version: 1.0 References: <20200111133410.2077135-1-jerinj@marvell.com> <20200113064941.2749356-1-jerinj@marvell.com> In-Reply-To: <20200113064941.2749356-1-jerinj@marvell.com> From: David Marchand Date: Mon, 13 Jan 2020 10:46:55 +0100 Message-ID: To: Jerin Jacob Kollanukkaran Cc: dev , Thomas Monjalon , Olivier Matz , Andrew Rybchenko , Bruce Richardson , "Ananyev, Konstantin" , Hemant Agrawal , Shahaf Shuler , Honnappa Nagarahalli , Gavin Hu , viktorin@rehivetech.com, David Christensen , "Burakov, Anatoly" , dpdk stable , Kevin Traynor , Luca Boccassi X-MC-Unique: qZCvPp9INGuiTjXqahiUAA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v3] mempool: fix mempool obj alignment for non x86 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On Mon, Jan 13, 2020 at 7:49 AM wrote: > > From: Jerin Jacob > > The existing optimize_object_size() function address the memory object > alignment constraint on x86 for better performance. > > Different (micro) architecture may have different memory alignment > constraint for better performance and it not the same as the existing > optimize_object_size(). > > Some use, XOR(kind of CRC) scheme to enable DRAM channel distribution > based on the address and some may have a different formula. > > Introducing arch_mem_object_align() function to abstract > the difference between different (micro) architectures to avoid > wasting memory for mempool object alignment for the architecture > that it is not required to do so. > > Details on the amount of memory saving: > > Currently, arm64 based architectures use the default (nchan=3D4, > nrank=3D1). The worst case is for an object whose size (including mempool > header) is 2 cache lines, where it is optimized to 3 cache lines (+50%). > > Examples for cache lines size =3D 64: > orig optimized > 64 -> 64 +0% > 128 -> 192 +50% > 192 -> 192 +0% > 256 -> 320 +25% > 320 -> 320 +0% > 384 -> 448 +16% > ... > 2304 -> 2368 +2.7% (~mbuf size) > > Additional details: > https://www.mail-archive.com/dev@dpdk.org/msg149157.html > > Fixes: af75078fece3 ("first public release") Weird to flag this as a problem in this sha1. x86 was the only architecture supported at the time. Either we mark the introduction of new architectures as the point of backport, or we remove this tag and just let Cc: stable@dpdk.org > Cc: stable@dpdk.org It seems more an optimisation than a fix to me, but in any case, the stable maintainers will be the judges. > > Signed-off-by: Jerin Jacob > Reviewed-by: Gavin Hu > --- > v3: > - Change comment for MEMPOOL_F_NO_SPREAD flag as > " Spreading among memory channels not required." (Stephen Hemminger) > > v2: > - Changed the return type of arch_mem_object_align() to "unsigned int" fr= om > "unsigned" to fix the checkpatch issues (Olivier Matz) > - Updated the comments for MEMPOOL_F_NO_SPREAD (Olivier Matz) > - Update the git comments to share the memory saving details. > > doc/guides/prog_guide/mempool_lib.rst | 6 +++--- > lib/librte_mempool/rte_mempool.c | 17 +++++++++++++---- > lib/librte_mempool/rte_mempool.h | 3 ++- > 3 files changed, 18 insertions(+), 8 deletions(-) > > diff --git a/doc/guides/prog_guide/mempool_lib.rst b/doc/guides/prog_guid= e/mempool_lib.rst > index 3bb84b0a6..eea7a2906 100644 > --- a/doc/guides/prog_guide/mempool_lib.rst > +++ b/doc/guides/prog_guide/mempool_lib.rst > @@ -27,10 +27,10 @@ In debug mode (CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG is ena= bled), > statistics about get from/put in the pool are stored in the mempool stru= cture. > Statistics are per-lcore to avoid concurrent access to statistics counte= rs. > > -Memory Alignment Constraints > ----------------------------- > +Memory Alignment Constraints on X86 architecture > +------------------------------------------------ Nit: afaics in the docs, x86 is preferred to X86. > > -Depending on hardware memory configuration, performance can be greatly i= mproved by adding a specific padding between objects. > +Depending on hardware memory configuration on X86 architecture, performa= nce can be greatly improved by adding a specific padding between objects. > The objective is to ensure that the beginning of each object starts on a= different channel and rank in memory so that all channels are equally load= ed. > > This is particularly true for packet buffers when doing L3 forwarding or= flow classification. --=20 David Marchand