From: Tariq Toukan <tariqt@nvidia.com>
To: Glenn Judd <gmj@meta.com>, Saeed Mahameed <saeedm@nvidia.com>,
Tariq Toukan <tariqt@nvidia.com>, Mark Bloch <mbloch@nvidia.com>,
Leon Romanovsky <leon@kernel.org>,
Khalid Manaa <khalidm@nvidia.com>,
Dragos Tatulea <dtatulea@nvidia.com>,
netdev@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v2] net/mlx5e: strip runt Ethernet padding in HW-GRO (SHAMPO)
Date: Tue, 4 Aug 2026 10:24:23 +0300 [thread overview]
Message-ID: <bd319706-b28b-4131-9dcb-11b586831723@nvidia.com> (raw)
In-Reply-To: <20260803214412.1714151-1-gmj@meta.com>
On 04/08/2026 0:44, Glenn Judd wrote:
> When hardware GRO (SHAMPO) coalesces a small IPv4/TCP segment
> that was padded up to the 60-byte minimum Ethernet frame, the trailing
> padding is folded into the merged payload.
>
> The selftest tools/testing/selftests/drivers/net/hw/gro.py subtest
> hw_ipv4_data_lrg_1byte sends {100, 1} expecting to receive {101}.
> In current code, it receives {106} (100 + 1 payload + 5 pad) instead.
>
> Fix is to compute the real (unpadded) frame length from the segment's
> IPv4 total (padded) length and drop the padding before it is merged.
>
> Fixes: 92552d3abd32 ("net/mlx5e: HW_GRO cqe handler implementation")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4-8
> Assisted-by: Codex:gpt-5.6
> Assisted-by: Meta:internal-AI-tooling
> Signed-off-by: Glenn Judd <gmj@meta.com>
> ---
>
> Notes:
> v2:
> - No functional change.
> - Address the netdev checkpatch 80-column warning.
> - Add a comment noting the IPv4 header offset intentionally mirrors the
> driver's existing no-IP-options logic (raised in review).
> Changing that logic is outside the scope of this change.
> v1: https://lore.kernel.org/netdev/20260731185442.2778723-1-gmj@meta.com/
>
Hi,
Please note that I posted comments on v1, ~1h before your v2.
prev parent reply other threads:[~2026-08-04 7:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 18:54 [PATCH net] " Glenn Judd
2026-08-03 20:30 ` Tariq Toukan
2026-08-03 21:44 ` [PATCH net v2] " Glenn Judd
2026-08-04 7:24 ` Tariq Toukan [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=bd319706-b28b-4131-9dcb-11b586831723@nvidia.com \
--to=tariqt@nvidia.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=dtatulea@nvidia.com \
--cc=edumazet@google.com \
--cc=gmj@meta.com \
--cc=khalidm@nvidia.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@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®