On Thu, 15 Jan 2026 19:57:44 +0000 Haiyang Zhang wrote: > > > 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.
