Re: [PATCH] ath10k: Make HTT fill size configurable

[Kalle Valo <kvalo@qca.qualcomm.com>]

Sujith Manoharan <sujith@msujith.org> writes:

> Kalle Valo wrote:
>> 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?
>
> We are limiting performance by restricting the fill size. A user
> will just use the default, which is still the same and remains
> unchanged. But, having a way to adjust this based on the platform
> seems reasonable to me and I think trying to change this value dynamically
> is overkill.

Did you read at all what I wrote above? For example, what if we later
don't actually use ATH10K_HTT_MAX_NUM_REFILL anymore?

And the fundamental problem is that I still don't know what fill value
you think is the best to use here, and that means neither will the
users. That's why the values need to be within ath10k, not expose driver
internals and use some magic numbers which are not available anywhere.

>> 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.
>
> I don't think a network driver should limit its performance with
> such profiles. Moreover, x86 can be slow too - at least, my 4 year
> old machine is. :-)

We are not limitting anything more. That's not any different from what
your patch does, just that the parameter name is different and the user
doesn't have direct access to the internal parameter. Let me explain a
bit more how that would work in this HTT fill case:

profile 0 (auto):
profile 1 (slow):
        htt_fill_size = ATH10K_HTT_MAX_NUM_REFILL
        break:
profile 2 (fast):
        htt_fill_size = 77 /* or whatever */
        break;

So in this method the user can still choose optimal settings for a
certain platform, I assume AP148 in this case, and not know about driver
internals. And if there are more parameters we need to change in the
future, we can use the same modparam to change that as well.

-- 
Kalle Valo