1. 19 2月, 2016 2 次提交
  2. 18 2月, 2016 12 次提交
  3. 17 2月, 2016 1 次提交
  4. 26 1月, 2016 1 次提交
  5. 08 1月, 2016 1 次提交
  6. 16 12月, 2015 1 次提交
  7. 03 12月, 2015 4 次提交
  8. 02 12月, 2015 1 次提交
  9. 26 11月, 2015 2 次提交
  10. 19 11月, 2015 1 次提交
  11. 23 10月, 2015 1 次提交
  12. 20 10月, 2015 4 次提交
  13. 16 10月, 2015 3 次提交
    • J
      drivers/net/intel: use napi_complete_done() · 32b3e08f
      Jesse Brandeburg 提交于
      As per Eric Dumazet's previous patches:
      (see commit (24d2e4a5) - tg3: use napi_complete_done())
      
      Quoting verbatim:
      Using napi_complete_done() instead of napi_complete() allows
      us to use /sys/class/net/ethX/gro_flush_timeout
      
      GRO layer can aggregate more packets if the flush is delayed a bit,
      without having to set too big coalescing parameters that impact
      latencies.
      </end quote>
      
      Tested
      configuration: low latency via ethtool -C ethx adaptive-rx off
      				rx-usecs 10 adaptive-tx off tx-usecs 15
      workload: streaming rx using netperf TCP_MAERTS
      
      igb:
      MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.0.0.1 () port 0 AF_INET : demo
      ...
      Interim result:  941.48 10^6bits/s over 1.000 seconds ending at 1440193171.589
      
      Alignment      Offset         Bytes    Bytes       Recvs   Bytes    Sends
      Local  Remote  Local  Remote  Xfered   Per                 Per
      Recv   Send    Recv   Send             Recv (avg)          Send (avg)
          8       8      0       0 1176930056  1475.36    797726   16384.00  71905
      
      MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.0.0.1 () port 0 AF_INET : demo
      ...
      Interim result:  941.49 10^6bits/s over 0.997 seconds ending at 1440193142.763
      
      Alignment      Offset         Bytes    Bytes       Recvs   Bytes    Sends
      Local  Remote  Local  Remote  Xfered   Per                 Per
      Recv   Send    Recv   Send             Recv (avg)          Send (avg)
          8       8      0       0 1175182320  50476.00     23282   16384.00  71816
      
      i40e:
      Hard to test because the traffic is incoming so fast (24Gb/s) that GRO
      always receives 87kB, even at the highest interrupt rate.
      
      Other drivers were only compile tested.
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      32b3e08f
    • A
      i40e/i40evf: Drop useless "IN_NETPOLL" flag · 8b650359
      Alexander Duyck 提交于
      The code in i40e and i40evf is using an "IN_NETPOLL" flag that has never
      added any value due to the fact that the Rx clean-up is handled in NAPI.
      As such the flag was set, the queue was scheduled via NAPI, and then polled
      from the netpoll controller and if any Rx packets were processed the were
      processed in the wrong context.
      
      In addition the flag itself just added an unneeded conditional to the
      hot-path so it can safely be dropped and save us a few instructions.
      Signed-off-by: NAlexander Duyck <aduyck@mirantis.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      8b650359
    • A
      i40e/i40evf: Fix handling of napi budget · c67caceb
      Alexander Duyck 提交于
      The polling routine for i40e was rounding up the budget for Rx cleanup to
      1.  This is incorrect as the netpoll poll call is expecting no Rx to be
      processed as the budget passed was 0.
      Signed-off-by: NAlexander Duyck <aduyck@mirantis.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c67caceb
  14. 09 10月, 2015 2 次提交
  15. 08 10月, 2015 1 次提交
  16. 04 10月, 2015 1 次提交
  17. 30 9月, 2015 2 次提交