Skip to content

L
linux
Switch branch/tag
  1. 14 Jun, 2010 21 commits
  3. 08 Jun, 2010 8 commits
  5. 07 Jun, 2010 9 commits
  7. 06 Jun, 2010 2 commits
    • Daniel Halperin's avatar
      iwlwifi: fix wrapping when handling aggregated batches · f668da2f
      Daniel Halperin authored 
      Fairly complex code in iwlagn_tx_status_reply_tx handle the status reports for
aggregated packet batches sent by the NIC. This code aims to handle the case
where the NIC retransmits failed packets from a previous batch; the status
information for these packets can sometimes be inserted in the middle of a
batch and are actually not in order by sequence number! (I verified this can
happen with printk's in the function.)

The code in question adaptively identifies the "first" frame of the batch,
taking into account that it may not be the one corresponding to the first agg
status report, and also handles the case when the set of sent packets wraps the
256-character entry buffer. It generates the agg->bitmap field of sent packets
which is later compared to the BlockAck response from the receiver to see which
frames of those sent in this batch were ACKed. A small logic error (wrapping by
0xff==255 instead of 0x100==256) was causing the agg->bitmap to be set
incorrectly.

Fix this wrapping code, and add extensive comments to clarify what is going on.
Signed-off-by: default avatarDaniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      f668da2f
    • Daniel Halperin's avatar
      iwlwifi: parse block ack responses correctly · 02cd8dee
      Daniel Halperin authored 
      Compressed BlockAck frames store the ACKs/NACKs in a 64-bit bitmap that starts
at the sequence number of the first frame sent in the aggregated batch. Note
that this is a selective ACKnowledgement following selective retransmission;
e.g., if frames 1,4-5 in a batch are ACKed then the next transmission will
include frames 2-3,6-10 (7 frames). In this latter case, the Compressed
BlockAck will not have all meaningful information in the low order bits -- the
semantically meaningful bits of the BA will be 0x1f3 (where the low-order frame
is seq 2).

The driver code originally just looked at the lower (in this case, 7) bits of
the BlockAck. In this case, the lower 7 bits of 0x1f3 => only 5 packets,
maximum, could ever be ACKed. In reality it should be looking at all of the
bits, filtered by those corresponding to packets that were actually sent. This
flaw meant that the number of correctly ACked packets could be significantly
underreported and might result in asynchronous state between TX and RX sides as
well as driver and uCode.

Fix this and also add a shortcut that doesn't require the code to loop through
all 64 bits of the bitmap but rather stops when no higher packets are ACKed.

In my experiments this fix greatly reduces throughput swing, making throughput
stable and high. It is also likely related to some of the stalls observed in
aggregation mode and maybe some of the buffer underruns observed, e.g.,

http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1968
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2098
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2018Signed-off-by: default avatarDaniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      02cd8dee
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7