Re: [PATCH] net/mlx5: fix calculating TSO inline size

On Sep 12, 2017, at 12:24 AM, Nélio Laranjeiro [off-list ref] wrote:

On Mon, Sep 11, 2017 at 03:17:44PM -0700, Yongseok Koh wrote:

quoted

On Mon, Sep 04, 2017 at 04:01:08PM +0200, Nélio Laranjeiro wrote:

quoted

Hi Yongseok,

Please see some comments below,

On Thu, Aug 31, 2017 at 09:27:06AM -0700, Yongseok Koh wrote:

quoted

Tx descriptor for TSO embeds packet header to be replicated. If Tx inline
is enabled, there could be additional packet data inlined with 4B inline
header ahead. And between the header and additional inlined packet data,
there may be padding to make the inline part aligned to
MLX5_WQE_DWORD_SIZE. In calculating the total size of inlined data, the
size of inline header and padding is missing.

Fixes: 3f13f8c23a7c ("net/mlx5: support hardware TSO")
Cc: stable@dpdk.org

Signed-off-by: Shahaf Shuler <redacted>
Signed-off-by: Yongseok Koh <redacted>
---
drivers/net/mlx5/mlx5_rxtx.c | 25 +++++++++----------------
1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index fe9e7eac0..f89fa40b5 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c

@@ -524,19 +521,20 @@ mlx5_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts, uint16_t pkts_n)

		}
		/* Inline if enough room. */
		if (inline_en || tso) {
+			uint32_t inl;
			uintptr_t end = (uintptr_t)
				(((uintptr_t)txq->wqes) +
				 (1 << txq->wqe_n) * MLX5_WQE_SIZE);
			unsigned int inline_room = max_inline *
						   RTE_CACHE_LINE_SIZE -
-						   (pkt_inline_sz - 2);
+						   (pkt_inline_sz - 2) -
+						   !!tso * sizeof(inl);

Is not it dangerous to assume inl will always be 4 bytes long?  Why not
writing the real value instead?

That was for readability of the code and uint32_t will be always 4bytes. But for
better readability, it should be 'inline_header' instead of 'inl' though. I'm
also okay with using "4" as well. Which way do you prefer?

I agree on both, I was not clear enough to explain my thought, if for some
reason the inl moves from uint32_t to uint16_t without touching the sizeof
later, it will cause an issue.

I tried to change the sizeof but I found that there are more "sizeof(inl)" in
the following lines. Changing all the sizeof would be beyond the scope of this
patch. So, how about leaving it as is for consistency?

Thanks
Yongseok