1. 19 2月, 2016 1 次提交
    • A
      i40e/i40evf: Drop outer checksum offload that was not requested · a9c9a81f
      Alexander Duyck 提交于
      The i40e and i40evf drivers contained code for inserting an outer checksum
      on UDP tunnels.  The issue however is that the upper levels of the stack
      never requested such an offload and it results in possible errors.
      
      In addition the same logic was being applied to the Rx side where it was
      attempting to validate the outer checksum, but the logic there was
      incorrect in that it was testing for the resultant sum to be equal to the
      header checksum instead of being equal to 0.
      
      Since this code is so massively flawed, and doing things that we didn't ask
      for it to do I am just dropping it, and will bring it back later to use as
      an offload for SKB_GSO_UDP_TUNNEL_CSUM which can make use of such a
      feature.
      
      As far as the Rx feature I am dropping it completely since it would need to
      be massively expanded and applied to IPv4 and IPv6 checksums for all parts,
      not just the one that supports Tx checksum offload for the outer.
      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>
      a9c9a81f
  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 3 次提交