Sujith Manoharan <sujith@xxxxxxxxxxx> writes: > From: Sujith Manoharan <c_manoha@xxxxxxxxxxxxxxxx> > > 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@xxxxxxxxxxxxxxxx> [...] > --- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
