DPDK patches and discussions
 help / color / mirror / Atom feed
From: Slava Ovsiienko <viacheslavo@mellanox.com>
To: "Phil Yang" <phil.yang@arm.com>,
	"Yongseok Koh" <yskoh@mellanox.com>,
	"Matan Azrad" <matan@mellanox.com>,
	"Nélio Laranjeiro" <nelio.laranjeiro@6wind.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: Thomas Monjalon <thomas@monjalon.net>,
	"jerinj@marvell.com" <jerinj@marvell.com>,
	"Honnappa.Nagarahalli@arm.com" <Honnappa.Nagarahalli@arm.com>,
	"gavin.hu@arm.com" <gavin.hu@arm.com>, "nd@arm.com" <nd@arm.com>,
	"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 2/2] net/mlx5: fix Tx CQ doorbell synchronization on aarch64
Date: Thu, 5 Sep 2019 12:12:02 +0000	[thread overview]
Message-ID: <AM4PR05MB3265863E5389F259DA22FB2FD2BB0@AM4PR05MB3265.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <1567680908-31210-2-git-send-email-phil.yang@arm.com>

Hi, Phil

This point is in datapath and performance is very critical.
The rte_cio_wmb() may take a lot of CPU cycles, waiting till all previous writes become
visible for all external (relating to core) agents. The Tx CQE doorbelling does not need
any writes to other locations to be completed, the only concern is not to reorder/merge
the writes to the same doorbell register of the same sending queue in the tx_burst()
internal sending loop/subsequent calls. 

As far as I know - the writes to the same location should not be reordered by any arch
(may be merged if memory settings allow this, it is not critical for CQE doorbell),
could you, please, explain why we need explicit hardware fence before CQE doorbell
update? Do you think doorbell write might be rearranged with previously reads from the ring
buffer?

WBR,
Slava

> -----Original Message-----
> From: Phil Yang <phil.yang@arm.com>
> Sent: Thursday, September 5, 2019 13:55
> To: Yongseok Koh <yskoh@mellanox.com>; Slava Ovsiienko
> <viacheslavo@mellanox.com>; Matan Azrad <matan@mellanox.com>; Nélio
> Laranjeiro <nelio.laranjeiro@6wind.com>; dev@dpdk.org
> Cc: Thomas Monjalon <thomas@monjalon.net>; jerinj@marvell.com;
> Honnappa.Nagarahalli@arm.com; gavin.hu@arm.com; nd@arm.com;
> stable@dpdk.org
> Subject: [PATCH 2/2] net/mlx5: fix Tx CQ doorbell synchronization on
> aarch64
> 
> For the weaker memory model processors, the compiler barrier is not
> sufficient to guarantee the coherent memory update be observed by I/O
> device. It needs the coherent I/O memory barrier to enforce the ordering of
> Tx completion queue doorbell operation.
> 
> Fixes: da1df1ccabad ("net/mlx5: fix completion queue drain loop")
> Cc: stable@dpdk.org
> 
> Suggested-by: Gavin Hu <gavin.hu@arm.com>
> Signed-off-by: Phil Yang <phil.yang@arm.com>
> Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> ---
>  drivers/net/mlx5/mlx5_rxtx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
> index 4c01187..c11148b 100644
> --- a/drivers/net/mlx5/mlx5_rxtx.c
> +++ b/drivers/net/mlx5/mlx5_rxtx.c
> @@ -2042,7 +2042,7 @@ mlx5_tx_comp_flush(struct mlx5_txq_data
> *restrict txq,
>  	} else {
>  		return;
>  	}
> -	rte_compiler_barrier();
> +	rte_cio_wmb();
>  	*txq->cq_db = rte_cpu_to_be_32(txq->cq_ci);
>  	if (likely(tail != txq->elts_tail)) {
>  		mlx5_tx_free_elts(txq, tail, olx);
> --
> 2.7.4


  reply	other threads:[~2019-09-05 12:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-05 10:55 [dpdk-dev] [PATCH 1/2] net/mlx5: fix Rx " Phil Yang
2019-09-05 10:55 ` [dpdk-dev] [PATCH 2/2] net/mlx5: fix Tx " Phil Yang
2019-09-05 12:12   ` Slava Ovsiienko [this message]
2019-09-06  7:20     ` Phil Yang (Arm Technology China)
2019-09-06 12:26       ` Slava Ovsiienko
2019-09-09 10:12         ` Phil Yang (Arm Technology China)
2019-09-09 11:29           ` Slava Ovsiienko
2019-09-10  9:22             ` Phil Yang (Arm Technology China)
2019-09-10  7:22 ` [dpdk-dev] [PATCH 1/2] net/mlx5: fix Rx " Matan Azrad
2019-09-12  8:29 ` Raslan Darawsheh

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=AM4PR05MB3265863E5389F259DA22FB2FD2BB0@AM4PR05MB3265.eurprd05.prod.outlook.com \
    --to=viacheslavo@mellanox.com \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=dev@dpdk.org \
    --cc=gavin.hu@arm.com \
    --cc=jerinj@marvell.com \
    --cc=matan@mellanox.com \
    --cc=nd@arm.com \
    --cc=nelio.laranjeiro@6wind.com \
    --cc=phil.yang@arm.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    --cc=yskoh@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 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).