Re: [PATCH V2 1/4] dmaengine: Add support to configure and read IRQ coalescing parameters

["Gupta, Suraj" <suraj.gupta2@amd.com>]

On 9/9/2026 6:20 PM, Vinod Koul wrote:
> On 07-09-26, 20:23, Gupta, Suraj wrote:
>>
>> Hi Vinod,
>> On 8/25/2025 5:00 PM, Vinod Koul wrote:
>>> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>>>
>>>
>>> On 23-07-25, 11:49, Gupta, Suraj wrote:
>>>>>>    struct dma_slave_caps {
>>>>>>         u32 src_addr_widths;
>>>>>> @@ -520,6 +528,8 @@ struct dma_slave_caps {
>>>>>>         bool cmd_terminate;
>>>>>>         enum dma_residue_granularity residue_granularity;
>>>>>>         bool descriptor_reuse;
>>>>>> +     u32 coalesce_cnt;
>>>>>> +     u32 coalesce_usecs;
>>>>>
>>>>> Why not selectively set interrupts for the descriptor. The dma descriptors are in order,
>>>>> so one a descriptor is notified and complete, you can also complete the descriptors
>>>>> before that. I would suggest to use that rather than define a new interface for this
>>>>>
>>>>
>>>> The reason I used struct dma_slave_config to pass coalesce and delay information to DMA driver is that the coalesce count is configured per channel in AXI DMA channel control register[1].
>>>> AXI DMA IP doesn't have provision to set interrupt per descriptor[2].
>>>> I can explore other ways to pass this information via struct dma_async_tx_descriptor or metadata, or any other way.
>>>> Please let me know your thoughts.
>>>
>>> dma_async_tx_descriptor has dma_ctrl_flags and one of them is
>>> DMA_PREP_INTERRUPT which you can set for a descriptor and control when
>>> you get the interrupt
>>>
>>> I am not a fan of adding custom interfaces.
>>>
>>> --
>>> ~Vinod
>>
>> Apologies for reviving this old thread. I got pulled onto other work and am
>> now picking this back up.
>> Reposting the context below so we can converge on the interface direction.
>>
>> As mentioned earlier, interrupt coalescing on AXI DMA/MCDMA is a per-channel
>> configuration (IRQThreshold + IRQDelay), not a per-descriptor attribute.
>> Because of this, DMA_PREP_INTERRUPT does not map cleanly to the underlying
>> hardware model:
>>
>> - The coalescing delay is a per-channel timeout expressed in microseconds,
>> whereas a boolean flag cannot represent a time-based value.
>> - Linux Dynamic Interrupt Moderation (DIM) adjusts both the coalescing
>> threshold and delay at runtime, requiring an atomic per-channel update.
>> Flags on already queued descriptors cannot provide this capability.
>>
>> DIM is important for modern Ethernet drivers because it balances throughput,
>> latency, and CPU overhead at high speeds.
>>
>> If adding a new interface to configure interrupt moderation parameters for
>> networking clients using DMAEngine is not preferred, would either of the
>> following approaches be acceptable?
>>
>> - Passing the coalescing parameters through per-descriptor metadata, or
>> - Using the existing Xilinx-specific struct xilinx_vdma_config from
>> include/linux/dma/xilinx_dma.h, which already provides coalesce and delay
>> fields.
>>
>> I initially avoided the latter in favor of a standard dmaengine interface
>> that could be used by other networking clients utilizing DMAEngine. However,
>> I'm open to either approach if it aligns better with the subsystem's
>> direction.
> 
> Given the above description, I somehow didnt feel that you can use
> existing flags. It is setting the flag per descriptor applies for that
> channel imo...
> 

You're right that the effect ends up being per-channel. The trouble is 
two-fold:

1. Coalescing here is two values, not one: a count (DMACR[23:16]) *and* 
a separate delay timer (DMACR[31:24]). A flag carries neither, so the 
DMA driver would have to infer the count by walking the queued 
descriptors and measuring the spacing between flagged ones before 
programming DMACR. That only holds while the flag pattern stays regular.

2. DIM re-tunes both the count and the delay at runtime, from a 
workqueue, on descriptors that are already queued. A flag can't be 
updated after submit, so DIM can't take effect until the queued ring 
drains -- whereas it needs an atomic per-channel update decoupled from 
submission. The practical cost is a stale window of up to a full ring 
depth: the channel keeps moderating at the old rate -- too many IRQs 
when DIM is trying to back off under load, or too much latency when it's 
trying to react quickly -- which defeats DIM's sub-millisecond feedback 
loop.

Happy to walk through a concrete RX/DIM timeline if useful, but that's 
the crux: the flag can express a static count, not the delay, and can't 
be re-tuned for already queued descriptors.

Regards,
Suraj