1. 06 7月, 2016 2 次提交
    • L
      iwlwifi: mvm: support dqa queue sharing · 42db09c1
      Liad Kaufman 提交于
      Support DQA queue sharing when no free queue exists for
      allocation to a STA that already exists. This means that
      a single queue will serve more than a single TID (although
      the RA will be the same for all TIDs served).
      
      We try to choose the lowest AC possible, to ensure the
      shared queues have the lowest possible combined AC
      requirements. The queue to share is chosen only from the
      same RA's DATA queues as follows (in descending priority):
       1. An AC_BE queue
       2. Same AC queue
       3. Highest AC queue that is lower than new AC
       4. Any existing AC (there always is at least 1 DATA queue)
      
      If any aggregations existed for any of the TIDs of the
      shared queue - they are stopped (the FW is notified), but
      no delBA is sent.
      Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      42db09c1
    • S
      iwlwifi: pcie: unify restock calls on init · 2047fa54
      Sara Sharon 提交于
      Currently code calls restock for mq devices during the init
      function, unlike sq where restock is called after init.
      This causes an harmless but alarming deadlock warning from
      lockdep, to fix this - unify the init code.
      Rename the restock functions while at it.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      2047fa54
  2. 01 7月, 2016 4 次提交
  3. 11 5月, 2016 10 次提交
  4. 12 4月, 2016 1 次提交
  5. 30 3月, 2016 12 次提交
  6. 20 3月, 2016 2 次提交
  7. 10 3月, 2016 2 次提交
    • G
      iwlwifi: pcie: avoid restocks inside rx loop if not emergency · e0e168dc
      Gregory Greenman 提交于
      When trying to reach high Rx throughput of more than 500Mbps on
      a device with a relatively weak CPU (Atom x5-Z8500), CPU utilization
      may become a bottleneck. Analysis showed that we are looping in
      iwl_pcie_rx_handle for very long periods which led to starvation
      of other threads (iwl_pcie_rx_handle runs with _bh disabled).
      We were handling Rx and allocating new buffers and the new buffers
      were ready quickly enough to be available before we had finished
      handling all the buffers available in the hardware. As a
      consequence, we called iwl_pcie_rxq_restock to refill the hardware
      with the new buffers, and start again handling new buffers without
      exiting the function. Since we read the hardware pointer again when
      we goto restart, new buffers were handled immediately instead of
      exiting the function.
      
      This patch avoids refilling RBs inside rx handling loop, unless an
      emergency situation is reached. It also doesn't read the hardware
      pointer again unless we are in an emergency (unlikely) case.
      This significantly reduce the maximal time we spend in
      iwl_pcie_rx_handle with _bh disabled.
      Signed-off-by: NGregory Greenman <gregory.greenman@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      e0e168dc
    • S
      iwlwifi: pcie: fine tune number of rxbs · 7b542436
      Sara Sharon 提交于
      We kick the allocator when we have 2 RBDs that don't have
      attached RBs, and the allocator allocates 8 RBs meaning
      that it needs another 6 RBDs to attach the RBs to.
      The design is that allocator should always have enough RBDs
      to fulfill requests, so we give in advance 6 RBDs to the
      allocator so that when it is kicked, it gets additional 2 RBDs
      and has enough RBDs.
      These RBDs were taken from the Rx queue itself, meaning
      that each Rx queue didn't have the maximal number of
      RBDs, but MAX - 6.
      Change initial number of RBDs in the system to include both
      queue size and allocator reserves.
      Note the multi-queue is always 511 instead of 512 to avoid a
      full queue since we cannot detect this state easily enough in
      the 9000 arch.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      7b542436
  8. 07 3月, 2016 3 次提交
  9. 02 3月, 2016 1 次提交
  10. 28 2月, 2016 3 次提交