[PATCH] ath10k: Make HTT fill size configurable

[Kalle Valo]

Sujith Manoharan <sujith at msujith.org> writes:

> From: Sujith Manoharan <c_manoha at qca.qualcomm.com>
>
> The HTT RX ring is replenished with a maximum of 16 buffers,
> but this might be insufficient when RX traffic is high.
> Not having enough RX buffers throttles the FW, resulting
> in low throughput.
>
> This patch adds a module parameter to adjust the fill size
> based on the platform/usage.
>
> Signed-off-by: Sujith Manoharan <c_manoha at qca.qualcomm.com>

[...]

> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -33,14 +33,17 @@
>  unsigned int ath10k_debug_mask;
>  static bool uart_print;
>  static bool skip_otp;
> +int htt_fill_size = ATH10K_HTT_MAX_NUM_REFILL;
>  
>  module_param_named(debug_mask, ath10k_debug_mask, uint, 0644);
>  module_param(uart_print, bool, 0644);
>  module_param(skip_otp, bool, 0644);
> +module_param(htt_fill_size, int, 0644);
>  
>  MODULE_PARM_DESC(debug_mask, "Debugging mask");
>  MODULE_PARM_DESC(uart_print, "Uart target debugging");
>  MODULE_PARM_DESC(skip_otp, "Skip otp failure for calibration in testmode");
> +MODULE_PARM_DESC(htt_fill_size, "HTT RX ring fill size");

I'm not sure if I really like this path of having interfaces to
configure driver internals. I suspect that if we add this, we will have
even more later. It's a lot more documenting for us and more work to the
users to understand what parameters they should use. Also this means
that testing will be more challenging as people will use different
values and results won't be comparable.

Isn't there any other way to solve the problem? Like automatically
changing the value somehow (no idea how) or some other means?

Or if nothing else helps, a crazy idea is to have some sort of platform
profile parameter:

0 = auto
1 = slow
2 = fast
3 = superfast (x86)

And then we would have preset values (not just htt_fill_size) within
ath10k and they get chosen based on the profile configured.

-- 
Kalle Valo