1. 11 10月, 2018 1 次提交
  2. 05 9月, 2018 3 次提交
  3. 19 6月, 2018 1 次提交
  4. 15 6月, 2018 1 次提交
  5. 23 2月, 2018 1 次提交
  6. 19 2月, 2018 1 次提交
  7. 02 10月, 2017 1 次提交
  8. 30 6月, 2017 1 次提交
  9. 13 6月, 2017 2 次提交
  10. 28 4月, 2017 1 次提交
  11. 27 4月, 2017 3 次提交
  12. 31 3月, 2017 1 次提交
  13. 06 3月, 2017 3 次提交
  14. 08 2月, 2017 1 次提交
  15. 27 1月, 2017 1 次提交
  16. 05 1月, 2017 1 次提交
  17. 27 10月, 2016 3 次提交
  18. 30 6月, 2016 2 次提交
  19. 06 4月, 2016 2 次提交
    • F
      mac80211: add A-MSDU tx support · 6e0456b5
      Felix Fietkau 提交于
      Requires software tx queueing and fast-xmit support. For good
      performance, drivers need frag_list support as well. This avoids the
      need for copying data of aggregated frames. Running without it is only
      supported for debugging purposes.
      
      To avoid performance and packet size issues, the rate control module or
      driver needs to limit the maximum A-MSDU size by setting
      max_rc_amsdu_len in struct ieee80211_sta.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      [fix locking issue]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6e0456b5
    • J
      mac80211: add fast-rx path · 49ddf8e6
      Johannes Berg 提交于
      The regular RX path has a lot of code, but with a few
      assumptions on the hardware it's possible to reduce the
      amount of code significantly. Currently the assumptions
      on the driver are the following:
       * hardware/driver reordering buffer (if supporting aggregation)
       * hardware/driver decryption & PN checking (if using encryption)
       * hardware/driver did de-duplication
       * hardware/driver did A-MSDU deaggregation
       * AP_LINK_PS is used (in AP mode)
       * no client powersave handling in mac80211 (in client mode)
      
      of which some are actually checked per packet:
       * de-duplication
       * PN checking
       * decryption
      and additionally packets must
       * not be A-MSDU (have been deaggregated by driver/device)
       * be data packets
       * not be fragmented
       * be unicast
       * have RFC 1042 header
      
      Additionally dynamically we assume:
       * no encryption or CCMP/GCMP, TKIP/WEP/other not allowed
       * station must be authorized
       * 4-addr format not enabled
      
      Some data needed for the RX path is cached in a new per-station
      "fast_rx" structure, so that we only need to look at this and
      the packet, no other memory when processing packets on the fast
      RX path.
      
      After doing the above per-packet checks, the data path collapses
      down to a pretty simple conversion function taking advantage of
      the data cached in the small fast_rx struct.
      
      This should speed up the RX processing, and will make it easier
      to reason about parallelizing RX (for which statistics will need
      to be per-CPU still.)
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      49ddf8e6
  20. 05 4月, 2016 1 次提交
  21. 24 2月, 2016 1 次提交
  22. 14 1月, 2016 1 次提交
  23. 13 10月, 2015 2 次提交
  24. 09 10月, 2015 1 次提交
  25. 22 9月, 2015 2 次提交
  26. 14 8月, 2015 1 次提交
  27. 27 1月, 2015 1 次提交