From: Yongseok Koh <yskoh@mellanox.com>
To: Shahaf Shuler <shahafs@mellanox.com>
Cc: dev <dev@dpdk.org>, dpdk stable <stable@dpdk.org>,
Kevin Traynor <ktraynor@redhat.com>
Subject: Re: [dpdk-dev] [PATCH] net/mlx5: revert mbuf address calculation for x86
Date: Wed, 27 Mar 2019 22:21:19 +0000 [thread overview]
Message-ID: <F56953E5-3B31-4644-A70D-379386E07410@mellanox.com> (raw)
Message-ID: <20190327222119.YjylCm9fa0SVc-TYi4tkRfadHDnKua03wUrUshA2Lfo@z> (raw)
In-Reply-To: <b10a4733-24f4-2639-25a5-98a5e6983538@redhat.com>
> On Mar 27, 2019, at 4:51 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>
> On 25/03/2019 19:13, Yongseok Koh wrote:
>> When replenishing mbufs on Rx, buffer address (mbuf->buf_addr) should be
>> loaded. non-x86 processors (mostly RISC such as ARM and Power) are more
>> vulnerable to load stall. For x86, reducing the number of instructions
>> seems to matter most.
>>
>> For x86, this is simply a load but for other architectures, it is
>> calculated from the address of mbuf structure by rte_mbuf_buf_addr()
>> without having to load the first cacheline of the mbuf.
>>
>
> Hi Yongseok,
>
>> Fixes: 12d468a62bc1 ("net/mlx5: fix instruction hotspot on replenishing Rx buffer")
>
> A similar backport was just added into 18.11.1-RC2, should it be
> reverted? I'm not keen to put another fix for it in for 18.11.1 at this
> stage, I think it can be part of 18.11.2. WDYT?
I spoke with Kevin and we decided to drop the old fix.
I have also dropped it from 17.11.6-rc1.
This new fix will be merged to 18.11.2.
I'll merge it to 17.11.6 (or 17.11.7) if it is merged in the master.
thanks,
Yongseok
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
>> ---
>> drivers/net/mlx5/mlx5_rxtx_vec.h | 14 +++++++++++++-
>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/mlx5/mlx5_rxtx_vec.h b/drivers/net/mlx5/mlx5_rxtx_vec.h
>> index 5df8e291e6..4220b08dd2 100644
>> --- a/drivers/net/mlx5/mlx5_rxtx_vec.h
>> +++ b/drivers/net/mlx5/mlx5_rxtx_vec.h
>> @@ -102,9 +102,21 @@ mlx5_rx_replenish_bulk_mbuf(struct mlx5_rxq_data *rxq, uint16_t n)
>> return;
>> }
>> for (i = 0; i < n; ++i) {
>> - void *buf_addr = rte_mbuf_buf_addr(elts[i], rxq->mp);
>> + void *buf_addr;
>>
>> + /*
>> + * Load the virtual address for Rx WQE. non-x86 processors
>> + * (mostly RISC such as ARM and Power) are more vulnerable to
>> + * load stall. For x86, reducing the number of instructions
>> + * seems to matter most.
>> + */
>> +#ifdef RTE_ARCH_X86_64
>> + buf_addr = elts[i]->buf_addr;
>> + assert(buf_addr == rte_mbuf_buf_addr(elts[i], rxq->mp));
>> +#else
>> + buf_addr = rte_mbuf_buf_addr(elts[i], rxq->mp);
>> assert(buf_addr == elts[i]->buf_addr);
>> +#endif
>> wq[i].addr = rte_cpu_to_be_64((uintptr_t)buf_addr +
>> RTE_PKTMBUF_HEADROOM);
>> /* If there's only one MR, no need to replace LKey in WQE. */
>>
>
next prev parent reply other threads:[~2019-03-27 22:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-25 19:13 Yongseok Koh
2019-03-25 19:13 ` Yongseok Koh
2019-03-27 11:51 ` Kevin Traynor
2019-03-27 11:51 ` Kevin Traynor
2019-03-27 22:21 ` Yongseok Koh [this message]
2019-03-27 22:21 ` Yongseok Koh
2019-04-01 10:57 ` Shahaf Shuler
2019-04-01 10:57 ` Shahaf Shuler
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=F56953E5-3B31-4644-A70D-379386E07410@mellanox.com \
--to=yskoh@mellanox.com \
--cc=dev@dpdk.org \
--cc=ktraynor@redhat.com \
--cc=shahafs@mellanox.com \
--cc=stable@dpdk.org \
/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).