[RFC PATCH v2] wifi: ath12k: service all RX rings in an interrupt group

[Aaradhana Sahu]

On 10/28/2026 7:52 AM, John Macias wrote:
> Hi Tamizh,
> 
> Thanks for reviewing this. You were right to question the grouping
> itself. I am withdrawing this RFC.
> 
> The reproducer is downstream only. The submitted base and ath-next at
> 7b14c8f4a961 have at most one RX ring per interrupt group for QCN9274,
> IPQ5332 and WCN7850, and there is no QCN6432 entry in that upstream
> source. The downstream QCN6432 mask groups REO rings 2 and 3 together.
> 
> Its hybrid bus provides eight DP MSI vectors, with ext group i using
> DP vector i % 8. The mask uses groups 0-5; empty groups request no IRQ,
> leaving DP vectors 6 and 7 unused. The host programs each ring's MSI
> data from its group's vector. Moving ring 3 to group 6 therefore gives
> each RX ring its own active vector and NAPI instance while retaining
> the original single-ring handler.
> 
> That configuration now works on the Slate 7 in a short hardware test.
> The tested module was built from the 25 October single-handler source
> with only the RX mask changed. All 16 four-second single-flow downloads
> completed, at 890-1166 Mb/s; the old mask and original handler completed
> 9 of 16 in the earlier 25 October test. An eight-stream, twenty-second
> download reached 1208 Mb/s, with the slowest stream at 72 Mb/s. All
> four REO rings received traffic, and the new DP-group interrupt was
> active. No warnings were recorded in the valid runs.
> 
> The driver reload also needed a Wi-Fi reload on the Flint peer to bring
> the backhaul back, as it did for the installed module. These were short
> tests in one session, not a soak or a measurement of CPU time or
> locking cost.
> 
> Your other points hold for v2 as posted. With two busy rings and a
> budget of 1, its fixed descending order serves only the higher ring;
> the lower ring received no service over 100 polls in an offline model.
> Each rx_process() call also takes srng->lock, and an empty grouped
> ring can be visited twice. I have not measured that cost.
> 
> For the tested downstream configuration, separating the groups avoids
> the need for this RX-handler change. I plan to address the mask there.
> If QCN6432 support goes upstream, it should use a suitable per-ring
> group configuration rather than inherit this grouped-mask problem.
> 
> Thanks,
> John
> 

Thanks for pointing this out. QCN6432 has a dedicated ring-mask configuration
in upstream series, with RX rings assigned to separate interrupt groups rather
than sharing a group.

The driver allocates 15 DP MSI vectors for up to 12 interrupt groups and assigns
a separate MSI descriptor and NAPI instance to each active group. Therefore,
the grouped-mask issue described in this thread should not apply to the QCN6432 series.

Please refer to the latest patch series:
https://patchwork.kernel.org/project/linux-wireless/cover/20261023-mpp-bringup-v3-0-19f3fcbf7b5f@oss.qualcomm.com/