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

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.

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

quoted

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.

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..