On Fri, 16 Jan 2026 16:44:33 +0000 Haiyang Zhang wrote: > > 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. > When the flag is set, the CQE coalescing will be enabled and put > up to 4 pkts in a CQE. > > > Please add both size and > > timeout. Expose the timeout as read only if your device doesn't support > > 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. > 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? 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.
