Need to get msdu-chaining working.

[Michal Kazior]

On 28 February 2014 02:18, Ben Greear <greearb at candelatech.com> wrote:
> On 02/26/2014 10:51 PM, Michal Kazior wrote:
>
>>>From what I understand chained msdu is a msdu that hasn't fit into the
>> rx buffer and is split across the popped amsdu list. I suspect only
>> the first msdu in chain has the htt_rx_desc and all other have not
>> (this is what the current code does, but you'll need to verify that).
>>
>> I would try to concatenate all msdus into one (lots of memcpy :( ) or
>> increase the HTT_RX_BUF_SIZE so that A-MSDU frames can fit into a
>> single buffer (hopefully FW/HW is capable of doing that).
>
> I got this working, basically using memcpy approach.
>
> Throughput is comparable what I was seeing on stock firmware,
> but I do notice an issue:

Doing memcpy() is pretty bad, though. It'll hurt you, sooner or later,
or hurt other with less powerful host systems.

The problem is chained msdus suggest A-MSDU rx. This means you
re-assemble the aggregate, just to pass it to mac80211 which splits
the frame into 802.3 frames (again, memcpy). This can easily flush you
d-cache.


> The reported rx speed is almost always 6Mbps when I drive at high speeds.
>
> (At low speeds I see rx rate reported at 1.3Gbps most of the time.)
>
> I am pretty sure this is related to the msdu-chaining somehow.
>
> There are lots of FIXME's in the ath10k_htt_rx_amsdu_pop method.
>
> Any idea where the rx rate problem might lie?

Interesting. Rx rates are computed from the htt_rx_indication
structure, not popped frames from rx ring. I'm guessing FW/HW doesn't
fill in some stuff for raw rx at all. You probably can't do much about
it if it's HW. You can probably hack your way around if it's just FW
not copying some register values.


Michał