Hi Vinod, Thanks for the review comments.
On 3/11/2025 2:30 AM, Vinod Koul wrote:
On 12-02-25, 17:35, Jyothi Kumar Seerapu wrote:
GSI hardware generates an interrupt for each transfer completion.
For multiple messages within a single transfer, this results in
N interrupts for N messages, leading to significant software
interrupt latency.
To mitigate this latency, utilize Block Event Interrupt (BEI) mechanism.
Enabling BEI instructs the GSI hardware to prevent interrupt generation
and BEI is disabled when an interrupt is necessary.
When using BEI, consider splitting a single multi-message transfer into
chunks of 8 messages internally and so interrupts are not expected for
the first 7 message completions, only the last message triggers
an interrupt, indicating the completion of 8 messages.
This BEI mechanism enhances overall transfer efficiency.
That sounds good but I dont like the idea that we add a custom interface
for this. Please use DMA_PREP_INTERRUPT instead. Adding this flag should
trigger N interrupts, absence of this should lead to Block events only
The DMA_PREP_INTERRUPT flag in DMA operations is used to indicate that
an interrupt should be generated once the DMA transfer is completed.
However, this flag itself does not block interrupt generation at the GPI
DMA hardware level. The GPI DMA hardware can still raise interrupts even
in the absence of the DMA_PREP_INTERRUPT flag.
To block interrupts at the GPI DMA hardware level, we need to use the
Block Event Interrupt (BEI) bit (as explained in the commit log).
As an example : for 100 transfers, we only want to receive one interrupt
at the 100th transfer. This helps us significantly reduce latencies, as
handling back-to-back 100 interrupts can take a few milliseconds.
Hope this explains it well. Please let me know if there are any other
concerns or feedback.
