From: Dragos Tatulea <dtatulea@nvidia.com>
To: Jiabin Deng <dengjiabin2023@gmail.com>, netdev@vger.kernel.org
Cc: Saeed Mahameed <saeedm@nvidia.com>,
Tariq Toukan <tariqt@nvidia.com>, Mark Bloch <mbloch@nvidia.com>,
Leon Romanovsky <leon@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] net/mlx5e: SHAMPO, Disable end padding when relaxed ordering is supported
Date: Fri, 6 Nov 2026 11:54:37 +0100 [thread overview]
Message-ID: <d02ac013-0ac5-4e91-a2de-796224a42693@nvidia.com> (raw)
In-Reply-To: <20261106083719.22798-1-dengjiabin2023@gmail.com>
Hi,
Thanks for sending the patch!
On 06.11.26 09:37, Jiabin Deng wrote:
> When SHAMPO and relaxed ordering writes are enabled, aligned RQ end
> padding can corrupt TCP data received directly into GPU DMA-BUF memory.
This is a generic issue, not just for GPU memory or DMA-BUF. Why not
just say: can corrupt received TCP data.
> The receiver gets the expected number of bytes, but some payload
> prefixes are zero-filled, with the corrupted ranges ending at 64-byte
> boundaries.
>
This is a bit confusing. Prefix sounds like the first bytes in the next
packet's data are padded. Why not just say that due to reordering,
the alignment padding bytes from the end of one packet are overwriting
data from the next packet.
> The current RQ end padding selection avoids alignment padding for LRO,
> but not for SHAMPO. Extend the condition to SHAMPO to prevent this
> corruption.
>
> The issue was observed in a two-host test using a BlueField-3 NIC and
> an NVIDIA H20 GPU. In the original test with MTU 1500, 354 of 400
> transfers contained corrupted data before the fix. After applying this
> change, all 400 transfers across eight message sizes from 32 KiB to
> 4 MiB, with 50 transfers per size, completed successfully, with no
> incorrect bytes or corrupted intervals.
>
> Fixes: e5ca8fb08ab2 ("net/mlx5e: Add control path for SHAMPO feature")
> Closes: https://lists.openwall.net/linux-kernel/2026/09/15/154
> Link: https://lists.openwall.net/linux-kernel/2026/10/20/1322
> Suggested-by: Dragos Tatulea <dtatulea@nvidia.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Jiabin Deng <dengjiabin2023@gmail.com>
Once you do the small fixes in the commit, you can add:
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Thanks,
Dragos
prev parent reply other threads:[~2026-11-06 10:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 8:37 Jiabin Deng
2026-11-06 10:54 ` Dragos Tatulea [this message]
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=d02ac013-0ac5-4e91-a2de-796224a42693@nvidia.com \
--to=dtatulea@nvidia.com \
--cc=dengjiabin2023@gmail.com \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.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
all inboxes | Powered by JetHome®