diff mbox series

net/mlx5: revert mbuf address calculation for x86

Message ID 20190325191310.20594-1-yskoh@mellanox.com (mailing list archive)
State Accepted, archived
Delegated to: Shahaf Shuler
Headers
Series net/mlx5: revert mbuf address calculation for x86 |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK
ci/intel-Performance-Testing success Performance Testing PASS
ci/mellanox-Performance-Testing fail Performance Testing issues

Commit Message

Yongseok Koh March 25, 2019, 7:13 p.m. UTC 
  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.

Fixes: 12d468a62bc1 ("net/mlx5: fix instruction hotspot on replenishing Rx buffer")
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(-)

Comments

Kevin Traynor March 27, 2019, 11:51 a.m. UTC | #1 
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?

thanks,
Kevin.

> 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. */
>
Yongseok Koh March 27, 2019, 10:21 p.m. UTC | #2 
> 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. */
>> 
>
Shahaf Shuler April 1, 2019, 10:57 a.m. UTC | #3 
Thursday, March 28, 2019 12:21 AM, Yongseok Koh:
>
> 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
> 
> 
> > 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.

Applied to next-net-mlx, thanks.
diff mbox series

Patch

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. */