DPDK patches and discussions
 help / color / mirror / Atom feed
From: David Marchand <david.marchand@redhat.com>
To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
Cc: dev <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>,
	 Olivier Matz <olivier.matz@6wind.com>,
	Andrew Rybchenko <arybchenko@solarflare.com>,
	 Bruce Richardson <bruce.richardson@intel.com>,
	 "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	Hemant Agrawal <hemant.agrawal@nxp.com>,
	 Shahaf Shuler <shahafs@mellanox.com>,
	Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>,
	 Gavin Hu <gavin.hu@arm.com>,
	viktorin@rehivetech.com,
	 David Christensen <drc@linux.vnet.ibm.com>,
	"Burakov, Anatoly" <anatoly.burakov@intel.com>,
	 dpdk stable <stable@dpdk.org>,
	Kevin Traynor <ktraynor@redhat.com>,
	Luca Boccassi <bluca@debian.org>
Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v3] mempool: fix mempool obj alignment for non x86
Date: Mon, 13 Jan 2020 10:46:55 +0100	[thread overview]
Message-ID: <CAJFAV8xxASnq91idx1nE2-iyMgAuPZw6Qo4WRYScz5H+ccp-pQ@mail.gmail.com> (raw)
In-Reply-To: <20200113064941.2749356-1-jerinj@marvell.com>

On Mon, Jan 13, 2020 at 7:49 AM <jerinj@marvell.com> wrote:
>
> From: Jerin Jacob <jerinj@marvell.com>
>
> 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=4,
> nrank=1). 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 = 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 <jerinj@marvell.com>
> Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> ---
> 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" from
>   "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_guide/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 enabled),
>  statistics about get from/put in the pool are stored in the mempool structure.
>  Statistics are per-lcore to avoid concurrent access to statistics counters.
>
> -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 improved by adding a specific padding between objects.
> +Depending on hardware memory configuration on X86 architecture, performance 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 loaded.
>
>  This is particularly true for packet buffers when doing L3 forwarding or flow classification.


-- 
David Marchand


  reply	other threads:[~2020-01-13  9:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-19 13:42 [dpdk-dev] [PATCH] " jerinj
2019-12-20  3:26 ` Gavin Hu
2019-12-20  3:45   ` Jerin Jacob
2019-12-20 10:54     ` [dpdk-dev] [PATCH] mempool: fix mempool obj alignment for nonx86 Morten Brørup
2019-12-20 15:55 ` [dpdk-dev] [PATCH] mempool: fix mempool obj alignment for non x86 Honnappa Nagarahalli
2019-12-20 16:55   ` Jerin Jacob
2019-12-20 21:07     ` Honnappa Nagarahalli
2019-12-21  5:06       ` Jerin Jacob
2019-12-27 15:54         ` Olivier Matz
2020-01-11 13:34 ` [dpdk-dev] [PATCH v2] " jerinj
2020-01-11 17:41   ` Stephen Hemminger
2020-01-13  6:49   ` [dpdk-dev] [PATCH v3] " jerinj
2020-01-13  9:46     ` David Marchand [this message]
2020-01-13 11:46       ` [dpdk-dev] [EXT] Re: [dpdk-stable] " Jerin Jacob Kollanukkaran
2020-01-14 21:06     ` [dpdk-dev] [PATCH v4] mempool: remove memory wastage on " jerinj
2020-01-16 13:10       ` Jerin Jacob
2020-01-20 12:24         ` Olivier Matz
2020-01-20 12:29           ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJFAV8xxASnq91idx1nE2-iyMgAuPZw6Qo4WRYScz5H+ccp-pQ@mail.gmail.com \
    --to=david.marchand@redhat.com \
    --cc=anatoly.burakov@intel.com \
    --cc=arybchenko@solarflare.com \
    --cc=bluca@debian.org \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=drc@linux.vnet.ibm.com \
    --cc=gavin.hu@arm.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=honnappa.nagarahalli@arm.com \
    --cc=jerinj@marvell.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=ktraynor@redhat.com \
    --cc=olivier.matz@6wind.com \
    --cc=shahafs@mellanox.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    --cc=viktorin@rehivetech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).