On Sat, 17 Jan 2026 18:01:18 +0000 Haiyang Zhang wrote: > > > 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. > > > 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 > > > 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? 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..
