1. 04 Feb, 2013 4 commits
  2. 31 Jan, 2013 8 commits
    • Stanislaw Gruszka's avatar
      mac80211: improve latency and throughput while software scanning · 3f892b61
      Stanislaw Gruszka authored
      Patch vastly improve latency while scanning. Slight throughput
      improvements were observed as well. Is intended for improve performance
      of voice and video applications, when scan is periodically requested by
      user space (i.e. default NetworkManager behaviour).
      
      Patch remove latency requirement based on PM_QOS_NETWORK_LATENCY,
      this value is 2000 seconds by default (i.e. approximately 0.5 hour !?!).
      
      Also remove listen interval requirement, which based on beaconing and
      depending on BSS parameters. It can make we stay off-channel for a
      second or more.
      
      Instead try to offer the best latency that we could, i.e. be off-channel
      no longer than PASSIVE channel scan time: 125 ms. That mean we will
      scan two ACTIVE channels and go back to on-channel, and one PASSIVE
      channel, and go back to on-channel.
      
      Patch also decrease PASSIVE channel scan time to about 110 ms.
      
      As drawback patch increase overall scan time. On my tests, when scanning
      both 2GHz and 5GHz bands, scanning time increase from 5 seconds up to 10
      seconds. Since that increase happen only when we are associated, I think
      it can be acceptable. If eventually better scan time is needed for
      situations when we lose signal and quickly need to decide to which AP
      roam, additional scan flag or parameter can be introduced.
      
      I tested patch by doing:
      
      while true; do iw dev wlan0 scan; sleep 3; done > /dev/null
      
      and
      
      ping -i0.2 -c 1000 HOST
      
      on remote and local machine, results are as below:
      
      * Ping from local periodically scanning machine to AP:
      Unpatched: rtt min/avg/max/mdev = 0.928/24.946/182.135/36.873 ms
      Patched:   rtt min/avg/max/mdev = 0.928/19.678/150.845/33.130 ms
      
      * Ping from remote machine to periodically scanning machine:
      Unpatched: rtt min/avg/max/mdev = 1.637/120.683/709.139/164.337 ms
      Patched:   rtt min/avg/max/mdev = 1.807/26.893/201.435/40.284 ms
      
      Throughput measured by scp show following results.
      
      * Upload to periodically scanning machine:
      Unpatched: 3.9MB/s   03:15
      Patched:   4.3MB/s   02:58
      
      * Download from periodically scanning machine:
      Unpatched: 5.5MB/s   02:17
      Patched:   6.2MB/s   02:02
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3f892b61
    • Johannes Berg's avatar
      mac80211: start auth/assoc timeout on frame status · 1672c0e3
      Johannes Berg authored
      When sending authentication/association frames they
      might take a bit of time to go out because we may
      have to synchronise with the AP, in particular in
      the case where it's really a P2P GO. In this case
      the 200ms fixed timeout could potentially be too
      short if the beacon interval is relatively large.
      
      For drivers that report TX status we can do better.
      Instead of starting the timeout directly, start it
      only when the frame status arrives. Since then the
      frame was out on the air, we can wait shorter (the
      typical response time is supposed to be 30ms, wait
      100ms.) Also, if the frame failed to be transmitted
      try again right away instead of waiting.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      1672c0e3
    • Johannes Berg's avatar
      cfg80211: remove free_priv BSS API · 3ff9a827
      Johannes Berg authored
      Now that mac80211 no longer uses this API, remove
      it completely. If anyone needs it again, we can
      revert this patch of course, but mac80211 was the
      only user right now.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3ff9a827
    • Johannes Berg's avatar
      mac80211: remove unused mesh data from bss · 0fe20add
      Johannes Berg authored
      These pointers/values are never used, remove them.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      0fe20add
    • Johannes Berg's avatar
      mac80211: remove last_probe_resp from bss · ce9877c0
      Johannes Berg authored
      We track this, but never use it, so we can
      just remove it.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      ce9877c0
    • Emmanuel Grumbach's avatar
      mac80211: inform the driver about update of dtim_period · c65dd147
      Emmanuel Grumbach authored
      Currently, when the driver requires the DTIM period,
      mac80211 will wait to hear a beacon before association.
      This behavior is suboptimal since some drivers may be
      able to deal with knowing the DTIM period after the
      association, if they get it at all.
      
      To address this, notify the drivers with bss_info_changed
      with the new BSS_CHANGED_DTIM_PERIOD flag when the DTIM
      becomes known. This might be when changing to associated,
      or later when the entire association was done with only
      probe response information.
      
      Rename the hardware flag for the current behaviour to
      IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC to more accurately
      reflect its behaviour. IEEE80211_HW_NEED_DTIM_PERIOD is
      no longer accurate as all drivers get the DTIM period
      now, just not before association.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      c65dd147
    • Johannes Berg's avatar
      mac80211: remove assoc data "sent_assoc" · fdcb7869
      Johannes Berg authored
      The field is never used, so remove it.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fdcb7869
    • Johannes Berg's avatar
      cfg80211/mac80211: support reporting wakeup reason · cd8f7cb4
      Johannes Berg authored
      When waking up from WoWLAN, it is useful to know
      what triggered the wakeup. Support reporting the
      wakeup reason(s) in cfg80211 (and a pass-through
      in mac80211) to allow userspace to know.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      cd8f7cb4
  3. 29 Jan, 2013 4 commits
  4. 28 Jan, 2013 2 commits
  5. 25 Jan, 2013 3 commits
  6. 24 Jan, 2013 7 commits
    • Johannes Berg's avatar
      mac80211: remove redundant check · 782d2673
      Johannes Berg authored
      There's no need to have two checks for "associated"
      in ieee80211_sta_restart(), make the first one locked
      to not race (unlikely at this point during resume)
      and remove the second check.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      782d2673
    • Simon Wunderlich's avatar
      cfg80211: fix channel check in cfg80211_can_use_iftype_chan · 683d41ae
      Simon Wunderlich authored
      In commit "cfg80211: check radar interface combinations" a regression
      was introduced which might lead to NULL dereference if the argument
      chan = NULL, which might happen in IBSS/wext case (and probably
      others).
      Signed-off-by: default avatarSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      683d41ae
    • Thomas Pedersen's avatar
      mac80211: support mesh rate updates · f68d776a
      Thomas Pedersen authored
      An existing mesh station entry may change its rate
      capabilities, so call rate_control_rate_update() to notify
      the rate control.
      Signed-off-by: default avatarThomas Pedersen <thomas@cozybit.com>
      [fix compilation]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f68d776a
    • Thomas Pedersen's avatar
      mac80211: clean up mesh sta allocation warning · 296fcba3
      Thomas Pedersen authored
      This refactoring fixes a "scheduling while atomic" warning
      when allocating a mesh station entry while holding the RCU
      read lock. Fix this by creating a new function
      mesh_sta_info_get(), which correctly handles the locking
      and returns under RCU.
      
      Also move some unnecessarily #ifdefed mesh station init
      code from sta_info_alloc() to __mesh_sta_info_alloc().
      Signed-off-by: default avatarThomas Pedersen <thomas@cozybit.com>
      [change code flow to make sparse happy]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      296fcba3
    • Bing Zhao's avatar
      ieee80211: define AKM suite selectors type 5, 6 and 7 · d437c86b
      Bing Zhao authored
      Reference: IEEE 802.11-2012 8.4.2.27.3 "AKM suites"
      Signed-off-by: default avatarBing Zhao <bzhao@marvell.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      d437c86b
    • Johannes Berg's avatar
      mac80211: fix aggregation state with current drivers · 8147dc7f
      Johannes Berg authored
      For drivers that don't actually flush their queues when
      aggregation stop with the IEEE80211_AMPDU_TX_STOP_FLUSH
      or IEEE80211_AMPDU_TX_STOP_FLUSH_CONT reasons is done,
      like iwlwifi or iwlegacy, mac80211 can then transmit on
      a TID that the driver still considers busy. This happens
      in the following way:
      
       - IEEE80211_AMPDU_TX_STOP_FLUSH requested
       - driver marks TID as emptying
       - mac80211 removes tid_tx data, this can copy packets
         to the TX pending queues and also let new packets
         through to the driver
       - driver gets unexpected TX as it wasn't completely
         converted to the new API
      
      In iwlwifi, this lead to the following warning:
      
      WARNING: at drivers/net/wireless/iwlwifi/dvm/tx.c:442 iwlagn_tx_skb+0xc47/0xce0
      Tx while agg.state = 4
      Modules linked in: [...]
      Pid: 0, comm: kworker/0:0 Tainted: G        W   3.1.0 #1
      Call Trace:
       [<c1046e42>] warn_slowpath_common+0x72/0xa0
       [<c1046f13>] warn_slowpath_fmt+0x33/0x40
       [<fddffa17>] iwlagn_tx_skb+0xc47/0xce0 [iwldvm]
       [<fddfcaa3>] iwlagn_mac_tx+0x23/0x40 [iwldvm]
       [<fd8c98b6>] __ieee80211_tx+0xf6/0x3c0 [mac80211]
       [<fd8cbe00>] ieee80211_tx+0xd0/0x100 [mac80211]
       [<fd8cc176>] ieee80211_xmit+0x96/0xe0 [mac80211]
       [<fd8cc578>] ieee80211_subif_start_xmit+0x348/0xc80 [mac80211]
       [<c1445207>] dev_hard_start_xmit+0x337/0x6d0
       [<c145eee9>] sch_direct_xmit+0xa9/0x210
       [<c14462c0>] dev_queue_xmit+0x1b0/0x8e0
      
      Fortunately, solving this problem is easy as the station
      is being destroyed, so such transmit packets can only
      happen due to races. Instead of trying to close the race
      just let the race not reach the drivers by making two
      changes:
       1) remove the explicit aggregation session teardown in
          the managed mode code, the same thing will be done
          when the station is removed, in __sta_info_destroy.
       2) When aggregation stop with AGG_STOP_DESTROY_STA is
          requested, leave the tid_tx data around as stopped.
          It will be cleared and freed in cleanup_single_sta
          later, but until then any racy packets will be put
          onto the tid_tx pending queue instead of transmitted
          which is fine since the station is being removed.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8147dc7f
    • Emmanuel Grumbach's avatar
      mac80211: provide the vif in rssi_callback · 887da917
      Emmanuel Grumbach authored
      Since drivers can support several BSS / P2P Client
      interfaces, the rssi callback needs to inform the driver
      about the interface teh rssi event relates to.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      887da917
  7. 22 Jan, 2013 12 commits