1. 21 7月, 2014 1 次提交
  2. 08 7月, 2014 2 次提交
  3. 06 7月, 2014 1 次提交
  4. 25 6月, 2014 1 次提交
  5. 13 5月, 2014 1 次提交
  6. 13 4月, 2014 1 次提交
    • J
      iwlwifi: pcie: implement GRO without NAPI · f14d6b39
      Johannes Berg 提交于
      Use the new NAPI infrastructure added to mac80211 to get
      GRO. We don't really implement NAPI since we don't have
      a real poll function and we never schedule a NAPI poll.
      Instead of this, we collect all the packets we got from a
      single interrupt and then call napi_gro_flush().
      
      This allows us to benefit from GRO. In half duplex medium
      like WiFi, its main advantage is that it reduces the number
      of TCP Acks, hence improving the TCP Rx performance.
      
      Since we call the Rx path with a spinlock held, remove
      the might_sleep mention from the op_mode's API.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Reviewed-by: NIdo Yariv <ido@wizery.com>
      [Squash different patches and rewrite the commit message]
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      f14d6b39
  7. 10 4月, 2014 1 次提交
  8. 16 3月, 2014 1 次提交
  9. 12 3月, 2014 2 次提交
  10. 27 2月, 2014 1 次提交
  11. 13 2月, 2014 2 次提交
  12. 04 2月, 2014 1 次提交
  13. 31 1月, 2014 1 次提交
  14. 14 1月, 2014 2 次提交
  15. 01 1月, 2014 1 次提交
  16. 18 12月, 2013 1 次提交
  17. 10 12月, 2013 2 次提交
  18. 11 10月, 2013 1 次提交
  19. 03 10月, 2013 2 次提交
  20. 12 8月, 2013 1 次提交
    • J
      mac80211: add control port protocol TX control flag · af61a165
      Johannes Berg 提交于
      A lot of drivers check the frame protocol for ETH_P_PAE,
      for various reasons (like making those more reliable).
      Add a new flags bitmap to the TX control info and a new
      flag indicating the control port protocol is in use to
      let all drivers also apply such logic to other control
      port protocols, should they be configured.
      
      Also use the new flag in the iwlwifi drivers.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      af61a165
  21. 06 8月, 2013 1 次提交
  22. 31 7月, 2013 1 次提交
  23. 13 6月, 2013 2 次提交
  24. 05 6月, 2013 1 次提交
  25. 04 6月, 2013 1 次提交
  26. 17 5月, 2013 1 次提交
    • E
      iwlwifi: mvm: fix aggregation drain flow · e3d4bc8c
      Emmanuel Grumbach 提交于
      Move the counter for non-AMPDU frames to mvm. It is needed
      for the drain flow which happens once the ieee80211_sta has
      been freed, so keeping it in iwl_mvm_sta which is embed into
      ieee80211_sta is not a good idea.
      
      Also, since its purpose it to remove the STA in the fw only
      after all the frames for this station have exited the shared
      Tx queues, we need to decrement it in the reclaim flow. This
      flow can happen after ieee80211_sta has been removed, which
      means that we have no iwl_mvm_sta there. So we can't know
      what is the vif type. Hence, we know audit these frames for
      all the vif types.
      In order to avoid spawning sta_drained_wk all the time, we
      now check that we are in a flow in which draining might
      happen - only when mvmsta is NULL. This is better than
      previous code that would spawn sta_drained_wk all the time
      in AP mode.
      
      Cc: stable@vger.kernel.org [3.9]
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Reviewed-by: NIlan Peer <ilan.peer@intel.com>
      Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e3d4bc8c
  27. 08 4月, 2013 1 次提交
  28. 04 4月, 2013 1 次提交
  29. 26 3月, 2013 1 次提交
  30. 20 3月, 2013 1 次提交
  31. 06 3月, 2013 2 次提交
  32. 04 3月, 2013 1 次提交
    • E
      iwlwifi: mvm: don't warn on normal BAR sending · 2470b36e
      Emmanuel Grumbach 提交于
      This flow happens when we get a failed single Tx response
      on an AMPDU queue. In this case, the frame won't be sent
      any more. So we need to move the window on the recipient
      side. This is done by a BAR.
      
      Now if we are in the following case: 10, 12 and 13 are ACKed
      and 11 isn't.
      
       10  11  12  13.
       V   X   V   V
      
      Then, 11 will be sent 16 times as an MPDU (as oppsed to
      A-MPDU). If this failed, we are entering the flow described
      above. So we need to send a BAR with ssn = 12.
      But in this case, the scheduler will tell us to free frames
      up to 13 (included).
      
      So, it is perfectly possible to get a failed single Tx
      response on an AMPDU queue that makes the scheduler's ssn
      jump by more than 1 single packet.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      2470b36e