Need to get msdu-chaining working.

[Michal Kazior]

On 3 March 2014 23:13, Ben Greear <greearb at candelatech.com> wrote:
> On 02/27/2014 11:36 PM, Michal Kazior wrote:
>
>>>> 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).
>
> Just FYI:  At least on my firmware in raw rx mode, increasing the
> HTT_RX_BUF_SIZE (to 4 * 1920) and at least some chaining remains.
> Performance did not change noticeably.  I'm using fairly powerful
> core i7 processor systems, so maybe the memcpy doesn't
> make enough difference to notice in my tests.
>
> I did not put any effort into figuring out why.

Getting rid of memcpy() was a huge performance win for AP135 and its
MIPS processor.


> I'm currently getting about 540Mbps upload TCP goodput,
> and only 420Mbps download TCP goodput.  Not sure why
> the discrepancy, but perhaps the rx raw performance
> is worse for a variety of reasons.  My firmware changes
> to support multiple stations to same AP may also be slowing
> things down, though these numbers are from  a single station
> test...

Hmm, I assume you test this without any bridging. It's probably going
to be a little slower due to tx timings being directly visible to the
TCP subsystem because both TCP and ath10k are locally on the same
machine. You could try moving the actual TCP endpoints behind bridges.

Or you're actually seeing the memcpy() at work...

Did you try to test performance on vanilla driver/firmware?


Michał