From: Thomas Monjalon <thomas@monjalon.net>
To: Alexander Kozyrev <akozyrev@mellanox.com>
Cc: stable@dpdk.org, dev@dpdk.org, viacheslavo@mellanox.com,
matan@mellanox.com, stable@dpdk.org,
Olivier Matz <olivier.matz@6wind.com>
Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v2] mbuf: optimize memory loads during mbuf freeing
Date: Tue, 31 Mar 2020 03:46:45 +0200 [thread overview]
Message-ID: <3368517.MVdQ21Qd56@xps> (raw)
In-Reply-To: <20200327081314.GD6327@platinum>
27/03/2020 09:13, Olivier Matz:
> On Fri, Mar 20, 2020 at 03:55:15PM +0000, Alexander Kozyrev wrote:
> > Introduction of pinned external buffers doubled memory loads in the
> > rte_pktmbuf_prefree_seg() function. Analysis of the generated assembly
> > code shows unnecessary load of the pool field of the rte_mbuf structure.
> > Here is the snippet of the assembly for "if (!RTE_MBUF_DIRECT(m))":
> > Before the change the code was:
> > movq 0x18(%rbx), %rax // load the ol_flags field
> > test %r13, %rax // check if ol_flags equals to 0x60...0
> > jz 0x9a8718 <Block 2> // jump out to "if (m->next != NULL)"
> > After the change the code became:
> > movq 0x18(%rbx), %rax // load ol_flags
> > test %r14, %rax // check if ol_flags equals to 0x60...0
> > jnz 0x9bea38 <Block 2> // jump in to "if (!RTE_MBUF_HAS_EXTBUF(m)"
> > movq 0x48(%rbx), %rax // load the pool field
> > jmp 0x9bea78 <Block 7> // jump out to "if (m->next != NULL)"
> > Look like this absolutely unneeded memory load of the pool field is an
> > optimization for the external buffer case in GCC (4.8.5), since Clang
> > generates the same assembly for both before and after the change versions.
> > Plus, GCC favors the external buffer case over the simple case.
> > This assembly code layout causes the performance degradation because the
> > rte_pktmbuf_prefree_seg() function is a part of a very hot path.
> > Workaround this compilation issue by moving the check for pinned buffer
> > apart from the check for external buffer and restore the initial code
> > flow that favors the direct mbuf case over the external one.
> >
> > Fixes: 6ef1107ad4c6 ("mbuf: detach mbuf with pinned external buffer")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Alexander Kozyrev <akozyrev@mellanox.com>
> > Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
>
> Acked-by: Olivier Matz <olivier.matz@6wind.com>
>
> Thanks!
Applied, thanks
prev parent reply other threads:[~2020-03-31 1:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-16 18:31 [dpdk-dev] [PATCH] mbuf: optimize memory loads during mbuf freeing Alexander Kozyrev
2020-03-19 9:30 ` Olivier Matz
2020-03-20 15:35 ` Alexander Kozyrev
2020-03-20 15:55 ` [dpdk-dev] [PATCH v2] " Alexander Kozyrev
2020-03-27 8:13 ` Olivier Matz
2020-03-31 1:46 ` Thomas Monjalon [this message]
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=3368517.MVdQ21Qd56@xps \
--to=thomas@monjalon.net \
--cc=akozyrev@mellanox.com \
--cc=dev@dpdk.org \
--cc=matan@mellanox.com \
--cc=olivier.matz@6wind.com \
--cc=stable@dpdk.org \
--cc=viacheslavo@mellanox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.