[RFC/RFT 5/7] ath10k: batch htt tx/rx completions

[Michal Kazior]

On 19 February 2014 16:10, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>> HTT Rx endpoint processes both frame rx
>> indications and frame tx completion indications.
>>
>> Those completions typically come in batches and
>> may be mixed so it makes sense to defer processing
>> hoping to get a bunch of them and take advantage
>> of hot caches.
>>
>> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
>
> [...]
>
>> @@ -270,7 +274,7 @@ static inline struct sk_buff *ath10k_htt_rx_netbuf_pop(struct ath10k_htt *htt)
>>       int idx;
>>       struct sk_buff *msdu;
>>
>> -     spin_lock_bh(&htt->rx_ring.lock);
>> +     lockdep_assert_held(&htt->rx_ring.lock);
>
> There are some locking changes which I think would be better to have in
> a separate patch.

I don't think it makes much sense. It seems silly to move a few lines
in one patch to move some of those lines again in another one.


>>       case HTT_T2H_MSG_TYPE_MGMT_TX_COMPLETION: {
>> +             struct htt_resp *resp = (struct htt_resp *)skb->data;
>>               struct htt_tx_done tx_done = {};
>>               int status = __le32_to_cpu(resp->mgmt_tx_completion.status);
>>
>> -             tx_done.msdu_id =
>> -                     __le32_to_cpu(resp->mgmt_tx_completion.desc_id);
>> +             tx_done.msdu_id = __le32_to_cpu(resp->mgmt_tx_completion.desc_id);
>
> I don't see any changes here.

Right. I'll cut this hunk out.


Michał