From: netdev-bot+sashiko@kernel.org
To: tariqt@nvidia.com
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, netdev@vger.kernel.org, pabeni@redhat.com,
sd@queasysnail.net, bobbyeshleman@meta.com, borisp@nvidia.com,
cjubran@nvidia.com, cratiu@nvidia.com, daniel.zahka@gmail.com,
doruk@0sec.ai, dtatulea@nvidia.com, gal@nvidia.com,
jianbol@nvidia.com, kees@kernel.org, leon@kernel.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-rdma@vger.kernel.org, mbloch@nvidia.com, petrm@nvidia.com,
raeds@nvidia.com, rrameshbabu@nvidia.com, saeedm@nvidia.com,
shuah@kernel.org, skhan@linuxfoundation.org, horms@kernel.org,
willemb@google.com, willemdebruijn.kernel@gmail.com
Subject: Re: [PATCH net-next V4 10/14] net/mlx5e: shampo: Flush session on PSP mismatch
Date: Thu, 10 Sep 2026 21:54:33 +0000 [thread overview]
Message-ID: <178907727309.219967.8541655657773031767@kernel.org> (raw)
In-Reply-To: <20260908065244.3799142-11-tariqt@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:
Critical: 0 · High: 0 · Medium: 1 · Low: 0
- [Medium] Understated impact / missing Fixes: tag.
--
net/mlx5e: shampo: Flush session on PSP mismatch
This adds mlx5e_hw_gro_psp_match() and wires it into the SHAMPO session
match test in mlx5e_handle_rx_cqe_mpwrq_shampo(), so a session is flushed
when the PSP status changes, when SPI/version differ, or when the CQE
indicates a non-decapsulated PSP packet.
(No Link: tags present in the commit header.)
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
> index e3f915beebe1..9eb11be7abe0 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
> @@ -2224,6 +2224,33 @@ static bool mlx5e_hw_gro_skb_has_enough_space(struct sk_buff *skb,
> return page_size * nr_frags + data_bcnt <= GRO_LEGACY_MAX_SIZE;
> }
>
> +static bool mlx5e_hw_gro_psp_match(struct sk_buff *skb, struct mlx5_cqe64 *cqe)
> +{
> +#ifdef CONFIG_MLX5_EN_PSP
> + struct psp_skb_ext *pse = skb_ext_find(skb, SKB_EXT_PSP);
> + bool is_psp = mlx5e_psp_is_rx_flow(cqe);
> +
> + if (likely(!is_psp && !pse))
> + return true;
> +
> + /* No match on PSP status change (no crypto -> crypto or vice-versa). */
> + if (unlikely(is_psp != !!pse))
> + return false;
> +
> + /* SPI and version are only available in CQE metadata for decap flows.
> + * Non-decap PSP cannot be matched here, force a flush.
> + */
> + if (unlikely(!mlx5e_psp_is_decap(cqe)))
> + return false;
[Severity: Medium]
Is the commit message understating what this particular hunk fixes? The
message says:
The session is also forcefully flushed if non-decapsulated packets are
received. This could happen if, for example, the decap table could not
be created so HW GRO is active but there's no decapsulation.
At the baseline commit (bc6fe9d301d5), non-decap looks like the only PSP
RX mode rather than an exceptional fallback:
mlx5e_psp_offload_handle_rx_skb() in en_accel/psp_rxtx.c only calls
psp_dev_rcv(), and mlx5e_psp_update_rx()/shampo_enabled() coupling between
PSP and NETIF_F_GRO_HW is only added by a later patch in this series.
If that is right, does the following sequence mis-deliver payload bytes
today, without this patch?
mlx5e_handle_rx_cqe_mpwrq_shampo()
-> HW coalesces several PSP datagrams sharing the outer IP/UDP 5-tuple
(mlx5e_shampo_update_hdr() -> mlx5e_shampo_update_ipv4_udp_hdr()
sets SKB_GSO_UDP_L4, so UDP flows are aggregated too)
-> mlx5e_shampo_complete_rx_cqe():
if (NAPI_GRO_CB(skb)->count != 1)
return false;
if (mlx5e_build_rx_skb(cqe, cqe_bcnt, rq, skb))
return true;
so mlx5e_build_rx_skb() -> mlx5e_psp_offload_handle_rx_skb() ->
psp_dev_rcv() runs only for the first record of a session. psp_dev_rcv()
in net/psp/psp_main.c strips one 16-byte PSP header plus one 16-byte
trailer and adjusts iph->tot_len once, so do the PSP headers and ICVs of
records 2..N remain embedded in the payload handed to the socket?
If so, should the commit message say that PSP + HW GRO
(ethtool -K <dev> rx-gro-hw on, also implied by tcp-data-split) is broken
in the current tree, and should the patch carry a Fixes: tag so stable
kernels shipping mlx5e PSP pick it up? A natural candidate looks like
29d7f433fcec ("net/mlx5e: Add Rx data path offload"), even if a backport
needs adjustment because mlx5e_psp_is_decap() is new in this series.
> +
> + /* No match on security parameters change. */
> + return pse->spi == mlx5e_psp_get_spi(cqe) &&
> + pse->version == mlx5e_psp_get_version(cqe);
> +#else
> + return true;
> +#endif
> +}
> +
> static void mlx5e_handle_rx_cqe_mpwrq_shampo(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe)
> {
> u16 data_bcnt = mpwrq_get_cqe_byte_cnt(cqe) - cqe->shampo.header_size;
> @@ -2266,8 +2293,9 @@ static void mlx5e_handle_rx_cqe_mpwrq_shampo(struct mlx5e_rq *rq, struct mlx5_cq
> }
>
> if (*skb &&
> - !(match && mlx5e_hw_gro_skb_has_enough_space(*skb, data_bcnt,
> - page_size))) {
> + !(match &&
> + mlx5e_hw_gro_skb_has_enough_space(*skb, data_bcnt, page_size) &&
> + mlx5e_hw_gro_psp_match(*skb, cqe))) {
> match = false;
> mlx5e_shampo_flush_skb(rq, cqe, match);
> }
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260908065244.3799142-1-tariqt%40nvidia.com
next prev parent reply other threads:[~2026-09-10 21:54 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 6:52 [PATCH net-next V4 00/14] net/mlx5e: Add support for HW-GRO to PSP Tariq Toukan
2026-09-08 6:52 ` [PATCH net-next V4 01/14] net/mlx5e: Generalize TC <-> IPsec mutual exclusion Tariq Toukan
2026-09-09 6:55 ` sashiko-bot
2026-09-10 21:54 ` netdev-bot+sashiko
2026-09-08 6:52 ` [PATCH net-next V4 02/14] net/mlx5e: ipsec: Block TC offload when IPsec is enabled Tariq Toukan
2026-09-09 6:55 ` sashiko-bot
2026-09-08 6:52 ` [PATCH net-next V4 03/14] net/mlx5e: psp: Block TC offload when PSP " Tariq Toukan
2026-09-09 6:55 ` sashiko-bot
2026-09-08 6:52 ` [PATCH net-next V4 04/14] net/mlx5e: macsec: Block TC offload when MACsec " Tariq Toukan
2026-09-09 6:55 ` sashiko-bot
2026-09-10 21:54 ` netdev-bot+sashiko
2026-09-08 6:52 ` [PATCH net-next V4 05/14] net/mlx5e: psp: Move RX marker from ft_metadata to flow_tag Tariq Toukan
2026-09-09 6:55 ` sashiko-bot
2026-09-08 6:52 ` [PATCH net-next V4 06/14] net/mlx5e: ipsec: " Tariq Toukan
2026-09-09 6:55 ` sashiko-bot
2026-09-08 6:52 ` [PATCH net-next V4 07/14] net/mlx5e: macsec: " Tariq Toukan
2026-09-09 6:55 ` sashiko-bot
2026-09-08 6:52 ` [PATCH net-next V4 08/14] net/mlx5e: psp: Handle HW-decapsulated RX PSP packets Tariq Toukan
2026-09-09 6:55 ` sashiko-bot
2026-09-08 6:52 ` [PATCH net-next V4 09/14] net/mlx5e: psp: Add an rx_decap steering table Tariq Toukan
2026-09-08 23:31 ` Daniel Zahka
2026-09-09 6:55 ` sashiko-bot
2026-09-10 21:54 ` netdev-bot+sashiko
2026-09-08 6:52 ` [PATCH net-next V4 10/14] net/mlx5e: shampo: Flush session on PSP mismatch Tariq Toukan
2026-09-09 6:55 ` sashiko-bot
2026-09-10 21:54 ` netdev-bot+sashiko [this message]
2026-09-08 6:52 ` [PATCH net-next V4 11/14] net/mlx5e: psp: Dynamically reconfigure based on SHAMPO mode Tariq Toukan
2026-09-09 6:55 ` sashiko-bot
2026-09-10 21:54 ` netdev-bot+sashiko
2026-09-08 6:52 ` [PATCH net-next V4 12/14] selftests: drv-net: psp: Extract shared helpers into psp_lib.py Tariq Toukan
2026-09-08 22:34 ` Daniel Zahka
2026-09-09 6:55 ` sashiko-bot
2026-09-08 6:52 ` [PATCH net-next V4 13/14] selftests: net: gro: Add PSP encapsulation and encryption Tariq Toukan
2026-09-08 22:55 ` Daniel Zahka
2026-09-09 6:55 ` sashiko-bot
2026-09-10 21:54 ` netdev-bot+sashiko
2026-09-08 6:52 ` [PATCH net-next V4 14/14] selftests: drv-net: Add PSP HW GRO conformance tests Tariq Toukan
2026-09-08 23:22 ` Daniel Zahka
2026-09-09 6:55 ` sashiko-bot
2026-09-10 21:54 ` netdev-bot+sashiko
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=178907727309.219967.8541655657773031767@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=bobbyeshleman@meta.com \
--cc=borisp@nvidia.com \
--cc=cjubran@nvidia.com \
--cc=cratiu@nvidia.com \
--cc=daniel.zahka@gmail.com \
--cc=davem@davemloft.net \
--cc=doruk@0sec.ai \
--cc=dtatulea@nvidia.com \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=horms@kernel.org \
--cc=jianbol@nvidia.com \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
--cc=raeds@nvidia.com \
--cc=rrameshbabu@nvidia.com \
--cc=saeedm@nvidia.com \
--cc=sd@queasysnail.net \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=tariqt@nvidia.com \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.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