DPDK patches and discussions
 help / color / mirror / Atom feed
From: Yongseok Koh <yskoh@mellanox.com>
To: David Marchand <david.marchand@redhat.com>
Cc: Olivier Matz <olivier.matz@6wind.com>,
	Shahaf Shuler <shahafs@mellanox.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] net/mlx5: fix instruction hotspot on replenishing Rx buffer
Date: Wed, 9 Jan 2019 10:11:15 +0000
Message-ID: <5C96B931-B5F5-4BAA-A23C-E87505B423D0@mellanox.com> (raw)
In-Reply-To: <CAJFAV8wZKRSR-_E0AY7oYjGJf=8PqWH8JE6NQE_UJiEh0xYe_A@mail.gmail.com>



> On Jan 9, 2019, at 2:05 AM, David Marchand <david.marchand@redhat.com> wrote:
> 
> 
> 
> On Wed, Jan 9, 2019 at 10:56 AM Yongseok Koh <yskoh@mellanox.com> wrote:
> 
> > On Jan 9, 2019, at 1:52 AM, Olivier Matz <olivier.matz@6wind.com> wrote:
> > 
> > On Wed, Jan 09, 2019 at 10:38:07AM +0100, David Marchand wrote:
> >> On Wed, Jan 9, 2019 at 9:54 AM Yongseok Koh <yskoh@mellanox.com> wrote:
> >> 
> >>> On replenishing Rx buffers for vectorized Rx, mbuf->buf_addr isn't needed
> >>> to be accessed as it is static and easily calculated from the mbuf address.
> >>> Accessing the mbuf content causes unnecessary load stall and it is worsened
> >>> on ARM.
> >>> 
> >>> Fixes: 545b884b1da3 ("net/mlx5: fix buffer address posting in SSE Rx")
> >>> Cc: stable@dpdk.org
> >>> 
> >>> Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
> >>> ---
> >>> drivers/net/mlx5/mlx5_rxtx_vec.h | 8 ++++++--
> >>> 1 file changed, 6 insertions(+), 2 deletions(-)
> >>> 
> >>> diff --git a/drivers/net/mlx5/mlx5_rxtx_vec.h
> >>> b/drivers/net/mlx5/mlx5_rxtx_vec.h
> >>> index fda7004e2d..ced5547307 100644
> >>> --- a/drivers/net/mlx5/mlx5_rxtx_vec.h
> >>> +++ b/drivers/net/mlx5/mlx5_rxtx_vec.h
> >>> @@ -102,8 +102,12 @@ mlx5_rx_replenish_bulk_mbuf(struct mlx5_rxq_data
> >>> *rxq, uint16_t n)
> >>>                return;
> >>>        }
> >>>        for (i = 0; i < n; ++i) {
> >>> -               wq[i].addr = rte_cpu_to_be_64((uintptr_t)elts[i]->buf_addr
> >>> +
> >>> -                                             RTE_PKTMBUF_HEADROOM);
> >>> +               uintptr_t buf_addr =
> >>> +                       (uintptr_t)elts[i] + sizeof(struct rte_mbuf) +
> >>> +                       rte_pktmbuf_priv_size(rxq->mp) +
> >>> RTE_PKTMBUF_HEADROOM;
> >>> +
> >>> +               assert(buf_addr == (uintptr_t)elts[i]->buf_addr);
> >>> +               wq[i].addr = rte_cpu_to_be_64(buf_addr);
> >>>                /* If there's only one MR, no need to replace LKey in WQE.
> >>> */
> >>>                if (unlikely(mlx5_mr_btree_len(&rxq->mr_ctrl.cache_bh) >
> >>> 1))
> >>>                        wq[i].lkey = mlx5_rx_mb2mr(rxq, elts[i]);
> >>> --
> >>> 2.11.0
> >>> 
> >>> 
> >> How about having a macro / inline in the mbuf api to get this information
> >> in a consistent/unique way ?
> >> I can see we have this calculation at least in rte_pktmbuf_init() and
> >> rte_pktmbuf_detach().
> > 
> > Agree. Maybe rte_mbuf_default_buf_addr(m) ?
> 
> I'm also okay to add. Will come up with a new patch.
> 
> > Side note, is the assert() correct in the patch? I'd say there's a
> > difference of RTE_PKTMBUF_HEADROOM between the 2 values.
> 
> Oops, my fault. Thanks for the catch, you saved a crash. :-)
> 
> Is this assert really necessary if we have a common macro ?
> I was under the impression that this assert is there to catch misalignement between the mbuf api and the driver.

It is still good to have. This can catch corruption of mbuf content which sometimes
happens due to wrong mbuf handling in PMD or potential HW memory corruption.


Thanks,
Yongseok

  reply	other threads:[~2019-01-09 10:11 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-09  8:54 Yongseok Koh
2019-01-09  9:38 ` David Marchand
2019-01-09  9:52   ` Olivier Matz
2019-01-09  9:56     ` Yongseok Koh
2019-01-09 10:05       ` David Marchand
2019-01-09 10:11         ` Yongseok Koh [this message]
2019-01-09 13:19 ` [dpdk-dev] [PATCH v2 1/2] mbuf: add function returning default buffer address Yongseok Koh
2019-01-09 13:19   ` [dpdk-dev] [PATCH v2 2/2] net/mlx5: fix instruction hotspot on replenishing Rx buffer Yongseok Koh
2019-01-09 13:46   ` [dpdk-dev] [PATCH v2 1/2] mbuf: add function returning default buffer address David Marchand
2019-01-10  1:39     ` Rami Rosen
2019-01-10 18:18       ` Yongseok Koh
2019-01-10 18:22     ` Yongseok Koh
2019-01-10 18:35 ` [dpdk-dev] [PATCH v3 " Yongseok Koh
2019-01-10 18:35   ` [dpdk-dev] [PATCH v3 2/2] net/mlx5: fix instruction hotspot on replenishing Rx buffer Yongseok Koh
2019-01-10 19:10     ` Shahaf Shuler
2019-01-11  8:14   ` [dpdk-dev] [PATCH v3 1/2] mbuf: add function returning default buffer address Andrew Rybchenko
2019-01-11 11:03     ` Yongseok Koh
2019-01-11 11:17       ` Andrew Rybchenko
2019-01-11 11:37         ` Yongseok Koh
2019-01-11 11:57         ` Bruce Richardson
2019-01-11 12:48           ` David Marchand
2019-01-14 15:51             ` Olivier Matz
2019-01-10 22:40 ` [dpdk-dev] [PATCH v4 " Yongseok Koh
2019-01-10 22:40   ` [dpdk-dev] [PATCH v4 2/2] net/mlx5: fix instruction hotspot on replenishing Rx buffer Yongseok Koh
2019-01-11  8:05   ` [dpdk-dev] [PATCH v4 1/2] mbuf: add function returning default buffer address Olivier Matz
2019-01-11  8:11   ` David Marchand
2019-01-11  8:32     ` David Marchand
2019-01-11 11:09       ` Yongseok Koh
2019-01-11 10:25     ` Thomas Monjalon
2019-01-14 21:16 ` [dpdk-dev] [PATCH v5 1/2] mbuf: add function returning " Yongseok Koh
2019-01-14 21:16   ` [dpdk-dev] [PATCH v5 2/2] net/mlx5: fix instruction hotspot on replenishing Rx buffer Yongseok Koh
2019-02-06 15:54     ` Kevin Traynor
2019-02-21 19:10       ` Kevin Traynor
2019-03-08  2:05         ` Yongseok Koh
2019-01-15  1:35   ` [dpdk-dev] [PATCH v5 1/2] mbuf: add function returning buffer address 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=5C96B931-B5F5-4BAA-A23C-E87505B423D0@mellanox.com \
    --to=yskoh@mellanox.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=olivier.matz@6wind.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

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git