On Thu, 15 Jan 2026 19:57:44 +0000 Haiyang Zhang wrote:

quoted

quoted

When coalescing is enabled, the device waits for packets which can
have the CQE coalesced with previous packet(s). That coalescing process
is finished (and a CQE written to the appropriate CQ) when the CQE is
filled with 4 pkts, or time expired, or other device specific logic is
satisfied.  

See, what I'm afraid is happening here is that you are enabling
completion coalescing (how long the device keeps the CQE pending).
Which is _not_ what rx_max_coalesced_frames controls for most NICs.
For most NICs rx_max_coalesced_frames controls IRQ generation logic.

The NIC first buffers up CQEs for typically single digit usecs, and
then once CQE timer exipred and writeback happened it starts an IRQ
coalescing timer. Once the IRQ coalescing timer expires IRQ is
triggered, which schedules NAPI. (broad strokes, obviously many
differences and optimizations exist)

Is my guess correct? Are you controlling CQE coalescing>

Can you control the timeout instead of the frame count?  

Our NIC's timeout value cannot be controlled by driver. Also, the
timeout may be changed in future NIC HW.

So, I use the ethtool/rx-frames, which is either 1 or 4 on our
NIC, to switch the CQE coalescing feature on/off.

I feel like this is not the first time I'm having a conversation with
you where you are not answering my direct questions, not just one
sliver. IDK why you're doing this, but being able to participate 
in  an email exchange is a bare minimum for participating upstream.
Please consider this a warning.

If I interpret your reply correctly you are indeed coalescing writeback.
You need to add a new param to the uAPI. Please add both size and
timeout. Expose the timeout as read only if your device doesn't support
controlling it per queue.