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

[John Macias]

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