Re: [RFC v2 05/10] ath10k: htt: High latency TX support

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

Erik Stromdahl <erik.stromdahl@gmail.com> writes:

> On 2017-06-13 19:38, Peter Oh wrote:
>> On 06/12/2017 08:03 AM, Erik Stromdahl wrote:
>>> Add HTT TX function for HL interfaces.
>>> Intended for SDIO and USB.
>>>
>>> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
>>> ---
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
>>> b/drivers/net/wireless/ath/ath10k/mac.c
>>> index 48418f9..c5fd803 100644
>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>> @@ -3572,7 +3572,10 @@ static int ath10k_mac_tx_submit(struct ath10k *a=
r,
>>>       switch (txpath) {
>>>       case ATH10K_MAC_TX_HTT:
>>> -        ret =3D ath10k_htt_tx(htt, txmode, skb);
>>> +        if (ar->is_high_latency)
>> Can we use function pointers at initial time to avoid condition check at=
 hot path?
>> I'm afraid adding more lines on hot path.
>
> I haven't made any comparison of assembly code between if-paths or
> function pointers, but since most architectures have conditional
> instructions I don't think the penalty is that big (if there is any
> penalty at all). There are plenty of other condition checks in the RX
> path (mac80211 is full of them), so I don't really see this as an
> issue.

Unless we can measure it I wouldn't be that worried either. Without
numbers trying to optimise is hard to get right.

> That being said, any improvement is always welcome (even micro
> optimizations if they are beneficial). I will think about this and see
> if adding function pointers can be done in a nice way.

But are function pointers really that much faster? You have to do a
function call anyway. And maybe use of likely() would be better, we want
to optimise for the low latency case anyway, but I still doubt we could
even measure that.

--=20
Kalle Valo=