From: sashiko-bot@kernel.org
To: "Haiyang Zhang" <haiyangz@linux.microsoft.com>
Cc: linux-hyperv@vger.kernel.org
Subject: Re: [PATCH net-next] net: mana: Extend RX CQE coalescing up to 8 packets
Date: Thu, 30 Jul 2026 22:53:25 +0000 [thread overview]
Message-ID: <20260730225325.B7AE11F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260729225235.3573786-1-haiyangz@linux.microsoft.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The `mana_rxcomp_perpkt_info` union defines the 8-packet mode layout in a way that incorrectly rearranges fields, contradicting the commit message and potentially causing the driver to read bogus packet lengths and hashes.
- [Medium] The driver accepts `rx-frames=8` via ethtool even when the hardware does not support it (`!gc->cqe8_coalescing_sup`), silently falling back to 4 packets instead of returning an error.
--
--- Patch [1]: [PATCH net-next] net: mana: Extend RX CQE coalescing up to 8 packets ---
commit 2083fcc78b90120f37ea18fdedab5ea909bd1068
Author: Haiyang Zhang <haiyangz@microsoft.com>
net: mana: Extend RX CQE coalescing up to 8 packets
To support up to 8 packets per CQE, put two packet lengths and hash values
into one PPI entry by using the reserved fields. Update ethtool handlers to
set this feature and per queue stat to show the coalesced CQE counters.
This feature is supported on NIC hardware showing the relevant PF flag.
> diff --git a/drivers/net/ethernet/microsoft/mana/mana_ethtool.c b/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
> index 9e31e2595ae32..8743f7edecbb8 100644
> --- a/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
> +++ b/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
[ ... ]
> @@ -514,8 +518,15 @@ static int mana_set_coalesce(struct net_device *ndev,
> saved.tx_dim_enabled = apc->tx_dim_enabled;
>
> saved.cqe_coalescing_enable = apc->cqe_coalescing_enable;
> + saved.cqe8_coalescing_enable = apc->cqe8_coalescing_enable;
> apc->cqe_coalescing_enable =
> - kernel_coal->rx_cqe_frames == MANA_RXCOMP_OOB_NUM_PPI;
> + kernel_coal->rx_cqe_frames >= MANA_RXCOMP_OOB_NUM_PPI;
> +
> + if (gc->cqe8_coalescing_sup)
> + apc->cqe8_coalescing_enable =
> + kernel_coal->rx_cqe_frames == MANA_CQE_COAL_PKTS_8;
> + else if (kernel_coal->rx_cqe_frames == MANA_CQE_COAL_PKTS_8)
> + netdev_info(ndev, "Fall back to RX-CQE x4 coalescing\n");
[Severity: Medium]
When the hardware does not support 8-packet coalescing, this code logs an
info message and falls back to 4 packets while still returning success (0).
Should this instead return an error code like -EINVAL or -EOPNOTSUPP?
Silently changing the requested parameter might break userspace configuration
scripts that expect ethtool to reject unsupported values.
> diff --git a/include/net/mana/mana.h b/include/net/mana/mana.h
> index 4d041fb8437f5..3ca1399a2fafa 100644
> --- a/include/net/mana/mana.h
> +++ b/include/net/mana/mana.h
[ ... ]
> @@ -238,12 +242,25 @@ struct mana_cqe_header {
> #define MANA_HASH_L4 \
> (NDIS_HASH_TCP_IPV4 | NDIS_HASH_UDP_IPV4 | NDIS_HASH_TCP_IPV6 | \
> NDIS_HASH_UDP_IPV6 | NDIS_HASH_TCP_IPV6_EX | NDIS_HASH_UDP_IPV6_EX)
> +#define MANA_HASH_ENABLE_SUPPORTED \
> + (NDIS_HASH_IPV4 | NDIS_HASH_TCP_IPV4 | NDIS_HASH_UDP_IPV4 | \
> + NDIS_HASH_IPV6 | NDIS_HASH_TCP_IPV6 | NDIS_HASH_UDP_IPV6)
> +
> +union mana_rxcomp_perpkt_info {
> + struct {
> + u32 pkt_len : 16;
> + u32 reserved1 : 16;
> + u32 reserved2;
> + u32 pkt_hash;
> + };
>
> -struct mana_rxcomp_perpkt_info {
> - u32 pkt_len : 16;
> - u32 reserved1 : 16;
> - u32 reserved2;
> - u32 pkt_hash;
> + /* Up to two pkts per PPI entry */
> + struct {
> + u32 pkt_hash0;
> + u16 pkt_len0;
> + u16 pkt_len1;
> + u32 pkt_hash1;
> + };
> }; /* HW DATA */
[Severity: High]
The commit message mentions using the reserved fields for the second packet,
but does this new structure layout match the original offsets?
In the original structure, pkt_len is at offset 0. However, the new 8-packet
struct places pkt_hash0 at offset 0.
On little-endian systems, this will overwrite the original pkt_len position
and move pkt_len0 and pkt_len1 to offsets 4 and 6. If the hardware still
populates the first packet's length at offset 0, could the driver misinterpret
the first 4 bytes as a hash and parse bogus packet lengths, potentially
causing 8-packet coalesced packets to be dropped as oversized?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260729225235.3573786-1-haiyangz@linux.microsoft.com?part=1
prev parent reply other threads:[~2026-07-30 22:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 22:52 [PATCH net-next] net: mana: Extend RX CQE coalescing up to 8 packets Haiyang Zhang
2026-07-30 15:54 ` Joe Damato
2026-07-30 21:10 ` [EXTERNAL] " Haiyang Zhang
2026-07-30 22:53 ` sashiko-bot [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=20260730225325.B7AE11F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=haiyangz@linux.microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.