-----Original Message-----
From: Jakub Kicinski <kuba@kernel.org>
Sent: Saturday, January 17, 2026 11:59 AM
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 Fri, 16 Jan 2026 16:44:33 +0000 Haiyang Zhang wrote:

quoted

quoted

You need to add a new param to the uAPI.

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]

quoted

When the flag is set, the CQE coalescing will be enabled and put
up to 4 pkts in a CQE.

quoted

Please add both size and
timeout. Expose the timeout as read only if your device doesn't

support

quoted

quoted

controlling it per queue.

Does the "size" mean the max pks per CQE (1 or 4)?

The definition of "size" is always a little funny when it comes to
coalescing and ringparam. In Tx does one frame mean one wire frame
or one TSO superframe? I wouldn't worry about the exact meaning of
size too much. Important thing is that user knows what making this
param smaller or larger will do.

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

quoted

The timeout value is not even exposed to driver, and subject to change
in the future. Also the HW mechanism is proprietary... So, can we not
"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.

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?

Thanks,
- Haiyang