1. 06 6月, 2012 2 次提交
  2. 17 5月, 2012 1 次提交
  3. 12 4月, 2012 1 次提交
    • J
      mac80211: add improved HW queue control · 3a25a8c8
      Johannes Berg 提交于
      mac80211 currently only supports one hardware queue
      per AC. This is already problematic for off-channel
      uses since if we go off channel while the BE queue
      is full and then try to send an off-channel frame
      the frame will never go out. This will become worse
      when we support multi-channel since then a queue on
      one channel might be full, but we have to stop the
      software queue for all channels. That is obviously
      not desirable.
      
      To address this problem allow drivers to register
      more hardware queues, and allow them to map them to
      virtual interfaces. When they stop a hardware queue
      the corresponding AC software queues on the correct
      interfaces will be stopped as well. Additionally,
      there's an off-channel queue to solve that problem
      and a per-interface after-DTIM beacon queue. This
      allows drivers to manage software queues closer to
      how the hardware works.
      
      Currently, there's a limit of 16 hardware queues.
      This may or may not be sufficient, we can adjust it
      as needed.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3a25a8c8
  4. 10 4月, 2012 1 次提交
    • F
      mac80211: optimize aggregation session timeout handling · 12d3952f
      Felix Fietkau 提交于
      Calling mod_timer from the rx/tx hotpath is somewhat expensive, and the
      timeout doesn't need to be so precise.
      
      Switch to a different strategy: Schedule the timer initially, store jiffies
      of all last rx/tx activity which would previously modify the timer, and
      let the timer re-arm itself after checking the last rx/tx timestamp.
      Make the session timers deferrable to avoid causing extra wakeups on systems
      running on battery.
      This visibly reduces CPU load under high network load on small embedded
      systems.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      12d3952f
  5. 20 12月, 2011 1 次提交
    • N
      mac80211: split addba retries in time · 84381b4e
      Nikolay Martynov 提交于
        Currently code allows three (HT_AGG_MAX_RETRIES) unanswered addba
      requests. When this limit is reached aggregation is turned off for
      given TID permanently. This doesn't seem right: three requests is
      not that much, some 'blackout' can happen, but effect of it affects
      whole connection indefinitely.
        This patch increases number of retries to 15. Also, when there have
      been 3 or more retries it splits further retries apart by 15 seconds
      instead of sending them in very short period of time.
      Signed-off-by: NNikolay Martynov <mar.kolya@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      84381b4e
  6. 16 12月, 2011 1 次提交
  7. 14 12月, 2011 1 次提交
    • Y
      mac80211: Purge A-MPDU TX queues before station destructions · 42624d49
      Yogesh Ashok Powar 提交于
      When a station leaves suddenly while ampdu traffic to that station is still
      running, there is a possibility that the ampdu pending queues are not freed due
      to a race condition leading to memory leaks. In '__sta_info_destroy' when we
      attempt to destroy the ampdu sessions in 'ieee80211_sta_tear_down_BA_sessions',
      the driver calls 'ieee80211_stop_tx_ba_cb_irqsafe' to delete the ampdu
      structures (tid_tx) and splice the pending queues and this job gets queued in
      sdata workqueue. However, the sta entry can get destroyed before the above work
      gets scheduled and hence the race.
      
      Purging the queues and freeing the tid_tx to avoid the leak. The better solution
      would be to fix the race, but that can be taken up in a separate patch.
      Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
      Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      42624d49
  8. 08 12月, 2011 1 次提交
    • J
      mac80211: fix another race in aggregation start · 15062e6a
      Johannes Berg 提交于
      Emmanuel noticed that when mac80211 stops the queues
      for aggregation that can leave a packet pending. This
      packet will be given to the driver after the AMPDU
      callback, but as a non-aggregated packet which messes
      up the sequence number etc.
      
      I also noticed by looking at the code that if packets
      are being processed while we clear the WANT_START bit,
      they might see it cleared already and queue up on
      tid_tx->pending. If the driver then rejects the new
      aggregation session we leak the packet.
      
      Fix both of these issues by changing this code to not
      stop the queues at all. Instead, let packets queue up
      on the tid_tx->pending queue instead of letting them
      get to the driver, and add code to recover properly
      in case the driver rejects the session.
      
      (The patch looks large because it has to move two
      functions to before their new use.)
      
      Cc: stable@vger.kernel.org
      Reported-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      15062e6a
  9. 07 12月, 2011 2 次提交
  10. 29 11月, 2011 5 次提交
  11. 09 11月, 2011 1 次提交
  12. 01 11月, 2011 1 次提交
  13. 01 10月, 2011 1 次提交
    • J
      mac80211: optimise station flags · c2c98fde
      Johannes Berg 提交于
      The flaglock in struct sta_info has long been
      something that I wanted to get rid of, this
      finally does the conversion to atomic bitops.
      
      The conversion itself is straight-forward in
      most places, a few things needed to change a
      bit since we can no longer use multiple bits
      at the same time.
      
      On x86-64, this is a fairly significant code
      size reduction:
         text	   data	    bss	    dec	    hex
       427861	  23648	   1008	 452517	  6e7a5	before
       425383	  23648	    976	 450007	  6ddd7	after
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c2c98fde
  14. 15 9月, 2011 1 次提交
  15. 14 9月, 2011 2 次提交
  16. 23 8月, 2011 1 次提交
  17. 09 8月, 2011 1 次提交
  18. 17 5月, 2011 2 次提交
    • J
      mac80211: sparse RCU annotations · 40b275b6
      Johannes Berg 提交于
      This adds sparse RCU annotations to most of
      mac80211, only the mesh code remains to be
      done.
      
      Due the the previous patches, the annotations
      are pretty simple. The only thing that this
      actually changes is removing the RCU usage of
      key->sta in debugfs since this pointer isn't
      actually an RCU-managed pointer (it only has
      a single assignment done before the key even
      goes live). As that is otherwise harmless, I
      decided to make it part of this patch.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      40b275b6
    • J
      mac80211: fix TX a-MPDU locking · ec034b20
      Johannes Berg 提交于
      During my quest to make mac80211 not have any RCU
      warnings from sparse, I came across the a-MPDU code
      again and it wasn't quite clear why it isn't racy.
      So instead of assigning the tid_tx array with just
      the spinlock held in ieee80211_start_tx_ba_session
      use a separate temporary array protected only by
      the spinlock and protect all assignments to the
      "live" array by both the spinlock and the mutex so
      that other code is easily verified to be correct.
      
      Due to pointer assignment atomicity I don't think
      this is a real issue, but I'm not sure, especially
      on Alpha the current code might be problematic.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ec034b20
  19. 08 5月, 2011 1 次提交
  20. 20 1月, 2011 2 次提交
    • J
      mac80211: allow advertising correct maximum aggregate size · 5dd36bc9
      Johannes Berg 提交于
      Currently, mac80211 always advertises that it may send
      up to 64 subframes in an aggregate. This is fine, since
      it's the max, but might as well be set to zero instead
      since it doesn't have any information.
      
      However, drivers might have that information, so allow
      them to set a variable giving it, which will then be
      used. The default of zero will be fine since to the
      peer that means we don't know and it will just use its
      own limit for the buffer size.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5dd36bc9
    • J
      mac80211: track receiver's aggregation reorder buffer size · 0b01f030
      Johannes Berg 提交于
      The aggregation code currently doesn't implement the
      buffer size negotiation. It will always request a max
      buffer size (which is fine, if a little pointless, as
      the mac80211 code doesn't know and might just use 0
      instead), but if the peer requests a smaller size it
      isn't possible to honour this request.
      
      In order to fix this, look at the buffer size in the
      addBA response frame, keep track of it and pass it to
      the driver in the ampdu_action callback when called
      with the IEEE80211_AMPDU_TX_OPERATIONAL action. That
      way the driver can limit the number of subframes in
      aggregates appropriately.
      
      Note that this doesn't fix any drivers apart from the
      addition of the new argument -- they all need to be
      updated separately to use this variable!
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0b01f030
  21. 16 12月, 2010 1 次提交
  22. 07 10月, 2010 2 次提交
  23. 15 6月, 2010 8 次提交