Need to get msdu-chaining working.

Ben Greear greearb at
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> 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.


Ben Greear <greearb at>
Candela Technologies Inc

More information about the ath10k mailing list