Need to get msdu-chaining working.
Ben Greear
greearb at candelatech.com
Thu Feb 27 11:08:29 EST 2014
On 02/26/2014 10:51 PM, Michal Kazior wrote:
> On 27 February 2014 00:38, Ben Greear <greearb at candelatech.com> wrote:
>>
>> I'm using raw-rx mode in my firmware, and it's throughput is
>> extremely poor at higher speeds. I see large numbers of warnings
>> about msdu_chaining, so I suspect this may be the reason.
>
> I assume this requires your custom FW?
Yes. I am not sure you can use raw tx with standard firmware (yet)?
Or at least, you cannot have tx cooked and rx raw.
>> Does anyone have any suggestions for what needs to be done
>> to handle these sorts of frames properly?
>>
>> /* FIXME: we do not support chaining yet.
>> * this needs investigation */
>> if (msdu_chaining) {
>> ath10k_warn("htt rx msdu_chaining is true\n");
>> ath10k_htt_rx_free_msdu_chain(msdu_head);
>> continue;
>> }
>
>>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 think in raw mode the hardware/firmware may not try to re-assemble the skb,
or also when no peer object can be found. This might be an issue in monitor
mode as well, but I'm not certain about that.
I think there is a way to chain skb data chunks w/out doing the copying,
but I am not certain how that would be done properly.
Thanks,
Ben
--
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc http://www.candelatech.com
More information about the ath10k
mailing list