On Mon, Oct 30, 2017 at 10:07:28AM +0000, Matan Azrad wrote:
> Replace most of the memory barriers by compiler barriers since they are
> all targeted to the DRAM; This improves code efficiency for systems
> which force store order between different addresses.
>
> Only the doorbell record store should be protected by memory barrier
> since it is targeted to the PCI memory domain.
>
> Limit pre byte count store compiler barrier for systems with cache line
> size smaller than 64B (TXBB size).
>
> Signed-off-by: Matan Azrad <ma...@mellanox.com>
This sounds like an interesting performance improvement, can you share the
typical or expected amount (percentage/hard numbers) for a given use case as
part of the commit log?
More comments below.
> ---
> drivers/net/mlx4/mlx4_rxtx.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/mlx4/mlx4_rxtx.c b/drivers/net/mlx4/mlx4_rxtx.c
> index 8ea8851..482c399 100644
> --- a/drivers/net/mlx4/mlx4_rxtx.c
> +++ b/drivers/net/mlx4/mlx4_rxtx.c
> @@ -168,7 +168,7 @@ struct pv {
> /*
> * Make sure we read the CQE after we read the ownership bit.
> */
> - rte_rmb();
> + rte_io_rmb();
OK for this one since the rest of the code should not be run due to the
condition (I'm not even sure even a compiler barrier is necessary at all
here).
> #ifndef NDEBUG
> if (unlikely((cqe->owner_sr_opcode & MLX4_CQE_OPCODE_MASK) ==
> MLX4_CQE_OPCODE_ERROR)) {
> @@ -203,7 +203,7 @@ struct pv {
> */
> cq->cons_index = cons_index;
> *cq->set_ci_db = rte_cpu_to_be_32(cq->cons_index & MLX4_CQ_DB_CI_MASK);
> - rte_wmb();
> + rte_io_wmb();
This one could be removed entirely as well, which is more or less what the
move to a compiler barrier does. Nothing in subsequent code depends on this
doorbell being written, so this can piggy back on any subsequent rte_wmb().
On the other hand in my opinion a barrier (compiler or otherwise) might be
needed before the doorbell write, to make clear it cannot somehow be done
earlier in case something attempts to optimize it away.
> sq->tail = sq->tail + nr_txbbs;
> /* Update the list of packets posted for transmission. */
> elts_comp -= pkts;
> @@ -321,6 +321,7 @@ static int handle_multi_segs(struct rte_mbuf *buf,
> * control segment.
> */
> if ((uintptr_t)dseg & (uintptr_t)(MLX4_TXBB_SIZE - 1)) {
> +#if RTE_CACHE_LINE_SIZE < 64
> /*
> * Need a barrier here before writing the byte_count
> * fields to make sure that all the data is visible
> @@ -331,6 +332,7 @@ static int handle_multi_segs(struct rte_mbuf *buf,
> * data, and end up sending the wrong data.
> */
> rte_io_wmb();
> +#endif /* RTE_CACHE_LINE_SIZE */
Interesting one.
> dseg->byte_count = byte_count;
> } else {
> /*
> @@ -469,8 +471,7 @@ static int handle_multi_segs(struct rte_mbuf *buf,
> break;
> }
> #endif /* NDEBUG */
> - /* Need a barrier here before byte count store. */
> - rte_io_wmb();
> + /* Never be TXBB aligned, no need compiler barrier. */
The reason there was a barrier here at all was unclear, so if it's really
useless, you don't even need to describe why.
> dseg->byte_count = rte_cpu_to_be_32(buf->data_len);
>
> /* Fill the control parameters for this packet. */
> @@ -533,7 +534,7 @@ static int handle_multi_segs(struct rte_mbuf *buf,
> * setting ownership bit (because HW can start
> * executing as soon as we do).
> */
> - rte_wmb();
> + rte_io_wmb();
This one looks dangerous. A compiler barrier is not strong enough to
guarantee the order in which CPU will execute instructions, it only makes
sure what follows the barrier doesn't appear before it in the generated
code.
Unless the comment above this barrier is wrong, this change may cause
hard-to-debug issues down the road, you should drop it.
> ctrl->owner_opcode = rte_cpu_to_be_32(owner_opcode |
> ((sq->head & sq->txbb_cnt) ?
> MLX4_BIT_WQE_OWN : 0));
> --
> 1.8.3.1
>
--
Adrien Mazarguil
6WIND
