-----Original Message-----
From: Jakub Kicinski <kuba@kernel.org>
Sent: Saturday, January 17, 2026 5:49 PM
To: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Haiyang Zhang <redacted>; linux-
hyperv@vger.kernel.org; netdev@vger.kernel.org; KY Srinivasan
[off-list ref]; Wei Liu [off-list ref]; Dexuan Cui
[off-list ref]; Long Li [off-list ref]; Andrew Lunn
[off-list ref]; David S. Miller [off-list ref]; Eric
Dumazet [off-list ref]; Paolo Abeni [off-list ref]; Konstantin
Taranov [off-list ref]; Simon Horman [off-list ref]; Erni
Sri Satya Vennela [off-list ref]; Shradha Gupta
[off-list ref]; Saurabh Sengar
[off-list ref]; Aditya Garg
[off-list ref]; Dipayaan Roy
[off-list ref]; Shiraz Saleem
[off-list ref]; linux-kernel@vger.kernel.org; linux-
rdma@vger.kernel.org; Paul Rosswurm [off-list ref]
Subject: Re: [EXTERNAL] Re: [PATCH V2,net-next, 1/2] net: mana: Add
support for coalesced RX packets on CQE

On Sat, 17 Jan 2026 18:01:18 +0000 Haiyang Zhang wrote:

quoted

quoted

quoted

Since this feature is not common to other NICs, can we use an
ethtool private flag instead?

It's extremely common. Descriptor writeback at the granularity of one
packet would kill PCIe performance. We just don't have uAPI so NICs
either don't expose the knob or "reuse" another coalescing param.

I see. So how about adding a new param like below to "ethtool -C"?
ethtool -C|--coalesce devname [rx-cqe-coalesce on|off]

I don't think we need on / off, just the params.
If someone needs on / off setting - the size to 1 is basically off.

Ok --
I will add a numerical param "rx-cqe-frames" to "ethtool -C":
  ethtool -C|--coalesce devname [rx-cqe-frames N]
   //Accepts 1 or 4 frames/CQE for this NIC

quoted

quoted

quoted

When the flag is set, the CQE coalescing will be enabled and put
up to 4 pkts in a CQE. support
Does the "size" mean the max pks per CQE (1 or 4)?

 [...]

In "ethtool -c" output, add a new value like this?
rx-cqe-frames:      (1 or 4 frames/CQE for this NIC)

SG

Thanks.

quoted

quoted

quoted

The timeout value is not even exposed to driver, and subject to

change

quoted

quoted

quoted

in the future. Also the HW mechanism is proprietary... So, can we

not

quoted

quoted

quoted

"expose" the timeout value in "ethtool -c" outputs, because it's not
available at driver level?

Add it to the FW API and have FW send the current value to the driver?

I don't know where is the timeout value in the HW / FW layers. Adding
new info to the HW/FW API needs other team's approval, and their work,
which will need a complex process and a long time.

quoted

You were concerned (in the commit msg) that there's a latency cost,
which is fair but I think for 99% of users 2usec is absolutely
not detectable (it takes longer for the CPU to wake). So I think it'd
be very valuable to the user to understand the order of magnitude of
latency we're talking about here.

For now, may I document the 2us in the patch description? And add a
new item to the "ethtool -c" output, like "rx-cqe-usecs", label is as
"n/a" for now, while we work out with other teams on the time value
API at HW/FW layers? So, this CQE coalescing feature support won't be
blocked by this "2usec" info API for a long time?

Please do it right. We are in no rush upstream. It can't be that hard
to add a single API to the FW within a single organization..

I will discuss this with our HW/FW teams.

Thanks,
- Haiyang