1. 14 7月, 2012 2 次提交
  2. 01 7月, 2012 1 次提交
    • B
      e1000e: remove use of IP payload checksum · 2e1706f2
      Bruce Allan 提交于
      Currently only used when packet split mode is enabled with jumbo frames,
      IP payload checksum (for fragmented UDP packets) is mutually exclusive with
      receive hashing offload since the hardware uses the same space in the
      receive descriptor for the hardware-provided packet checksum and the RSS
      hash, respectively.  Users currently must disable jumbos when receive
      hashing offload is enabled, or vice versa, because of this incompatibility.
      Since testing has shown that IP payload checksum does not provide any real
      benefit, just remove it so that there is no longer a choice between jumbos
      or receive hashing offload but not both as done in other Intel GbE drivers
      (e.g. e1000, igb).
      
      Also, add a missing check for IP checksum error reported by the hardware;
      let the stack verify the checksum when this happens.
      
      CC: stable <stable@vger.kernel.org> [3.4]
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e1706f2
  3. 06 6月, 2012 1 次提交
  4. 02 6月, 2012 1 次提交
  5. 17 5月, 2012 1 次提交
  6. 10 5月, 2012 1 次提交
  7. 09 5月, 2012 1 次提交
  8. 05 5月, 2012 3 次提交
  9. 04 5月, 2012 2 次提交
  10. 03 5月, 2012 6 次提交
  11. 02 5月, 2012 3 次提交
  12. 01 5月, 2012 1 次提交
  13. 27 4月, 2012 4 次提交
  14. 25 4月, 2012 2 次提交
    • J
      e1000e: Fix default interrupt throttle rate not set in NIC HW · 727c356f
      Jeff Kirsher 提交于
      Based on the original patch from  Ying Cai <ycai@google.com>
      This change ensures that the itr/itr_setting adjustment logic is used,
      even for the default/compiled-in value.
      
      Context:
        When we changed the default InterruptThrottleRate value from default
        (3 = dynamic mode) to 8000 for example, only adapter->itr_setting
        (which controls interrupt coalescing mode) was set to 8000, but
        adapter->itr (which controls the value set in NIC register) was not
        updated accordingly. So from ethtool, it seemed the interrupt
        throttling is enabled at 8000 intr/s, but the NIC actually was
        running in dynamic mode which has lower CPU efficiency especially
        when throughput is not high.
      
      CC: Ying Cai <ycai@google.com>
      CC: David Decotigny <david.decotigny@google.com>
      Signed-off-by: NJeff Kirsher <jeffrey.kirsher@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      727c356f
    • P
      e1000e: MSI interrupt test failed, using legacy interrupt · 569a3aff
      Prasanna S Panchamukhi 提交于
      Following logs where seen on Systems with multiple NICs,
      while using MSI interrupts as shown below:
      
      Feb 16 15:09:32 (none) user.notice kernel: 0000:00:0d.0: lan0_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:32 (none) user.notice kernel: 0000:40:0d.0: wan0_1: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:32 (none) user.notice kernel: 0000:40:0d.0: lan0_1: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:32 (none) user.warn kernel: 0000:40:0e.0: wan4_0: MSI interrupt
      test failed, using legacy interrupt.
      Feb 16 15:09:32 (none) user.notice kernel: 0000:00:0e.0: wan1_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:00:0e.0: lan1_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:00:0f.0: wan2_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:00:0f.0: lan2_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:40:0a.0: wan3_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:40:0a.0: lan3_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:34 (none) user.notice kernel: 0000:40:0e.0: lan4_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:34 (none) user.notice kernel: 0000:40:0f.0: wan5_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:34 (none) user.notice kernel: 0000:40:0f.0: lan5_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      
      This patch fixes this problem by increasing the msleep from 50 to 100.
      Signed-off-by: NPrasanna S Panchamukhi <ppanchamukhi@riverbed.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      569a3aff
  15. 14 4月, 2012 3 次提交
  16. 04 4月, 2012 6 次提交
  17. 28 3月, 2012 1 次提交
  18. 20 3月, 2012 1 次提交