1. 22 11月, 2017 1 次提交
  2. 18 10月, 2017 1 次提交
  3. 09 8月, 2017 1 次提交
    • G
      igbvf: add lock around mailbox ops · 32652c2a
      Greg Edwards 提交于
      The PF driver assumes the VF will not send another mailbox message until
      the PF has written its reply to the previous message.  If the VF does,
      that message will be silently dropped by the PF before it writes its
      reply to the mailbox.  This results in a VF mailbox timeout for posted
      messages waiting for an ACK, and the VF is reset by the
      igbvf_watchdog_task in the VM.
      
      Add a lock around the VF mailbox ops to prevent the VF from sending
      another message while the PF is still processing the previous one.
      Signed-off-by: NGreg Edwards <gedwards@ddn.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      32652c2a
  4. 21 4月, 2017 2 次提交
  5. 02 12月, 2016 1 次提交
  6. 18 10月, 2016 1 次提交
    • J
      ethernet/intel: use core min/max MTU checking · 91c527a5
      Jarod Wilson 提交于
      e100: min_mtu 68, max_mtu 1500
      - remove e100_change_mtu entirely, is identical to old eth_change_mtu,
        and no longer serves a purpose. No need to set min_mtu or max_mtu
        explicitly, as ether_setup() will already set them to 68 and 1500.
      
      e1000: min_mtu 46, max_mtu 16110
      
      e1000e: min_mtu 68, max_mtu varies based on adapter
      
      fm10k: min_mtu 68, max_mtu 15342
      - remove fm10k_change_mtu entirely, does nothing now
      
      i40e: min_mtu 68, max_mtu 9706
      
      i40evf: min_mtu 68, max_mtu 9706
      
      igb: min_mtu 68, max_mtu 9216
      - There are two different "max" frame sizes claimed and both checked in
        the driver, the larger value wasn't relevant though, so I've set max_mtu
        to the smaller of the two values here to retain identical behavior.
      
      igbvf: min_mtu 68, max_mtu 9216
      - Same issue as igb duplicated
      
      ixgb: min_mtu 68, max_mtu 16114
      - Also remove pointless old == new check, as that's done in dev_set_mtu
      
      ixgbe: min_mtu 68, max_mtu 9710
      
      ixgbevf: min_mtu 68, max_mtu dependent on hardware/firmware
      - Some hw can only handle up to max_mtu 1504 on a vf, others 9710
      
      CC: netdev@vger.kernel.org
      CC: intel-wired-lan@lists.osuosl.org
      CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      91c527a5
  7. 28 9月, 2016 1 次提交
  8. 21 5月, 2016 2 次提交
  9. 14 5月, 2016 3 次提交
  10. 25 2月, 2016 2 次提交
    • J
      igbvf: remove "link is Up" message when registering mcast address · cc54a59a
      Jon Maxwell 提交于
      A similar issue was addressed a few years ago in the following thread:
      
      http://www.spinics.net/lists/netdev/msg245877.html
      
      At that time there were concerns that removing this statement may cause other
      side effects. However the submitter addressed those concerns. But the dialogue
      went cold. We have a new case where a customers application is registering and
      un-registering multicast addresses every few seconds. This is leading to many
      "Link is Up" messages in the logs as a result of the
      "netif_carrier_off(netdev)" statement called by igbvf_msix_other(). Also on
      some kernels it is interfering with the bonding driver causing it to failover
      and subsequently affecting connectivity.
      
      The Sourgeforge driver does not make this call and is therefore not affected.
      If there were any side effects I would expect that driver to also be affected.
      I have tested re-loading the igbvf driver and downing the adapter with the PF
      entity on the host where the VM has this patch. When I bring it back up again
      connectivity is restored as expected. Therefore I request that this patch gets
      submitted.
      Signed-off-by: NJon Maxwell <jmaxwell37@gmail.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      cc54a59a
    • A
      igbvf: Add support for generic Tx checksums · ea6ce602
      Alexander Duyck 提交于
      This patch adds support for generic Tx checksums to the igbvf driver.  It
      turns out this is actually pretty easy after going over the datasheet as we
      were doing a number of steps we didn't need to.
      
      In order to perform a Tx checksum for an L4 header we need to fill in the
      following fields in the Tx descriptor:
        MACLEN (maximum of 127), retrieved from:
      		skb_network_offset()
        IPLEN  (maximum of 511), retrieved from:
      		skb_checksum_start_offset() - skb_network_offset()
        TUCMD.L4T indicates offset and if checksum or crc32c, based on:
      		skb->csum_offset
      
      The added advantage to doing this is that we can support inner checksum
      offloads for tunnels and MPLS while still being able to transparently
      insert VLAN tags.
      
      I also took the opportunity to clean-up many of the feature flag
      configuration bits to make them a bit more consistent between drivers.  In
      the case of the VF drivers this meant adding support for SCTP CRCs, and
      inner checksum offloads for MPLS and various tunnel types.
      Signed-off-by: NAlexander Duyck <aduyck@mirantis.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      ea6ce602
  11. 16 10月, 2015 1 次提交
    • 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
  12. 23 9月, 2015 1 次提交
  13. 19 8月, 2015 1 次提交
    • S
      igbvf: clear buffer_info->dma after dma_unmap_single() · fae5ecae
      Stefan Assmann 提交于
      The driver doesn't clear buffer_info->dma after calling
      dma_unmap_single() in all cases. This has been discovered by changing
      the mtu twice, which caused the following backtrace.
      
      [   68.569280] WARNING: CPU: 2 PID: 1860 at drivers/iommu/intel-iommu.c:3517 intel_unmap+0x20c/0x220()
      [   68.579392] Driver unmaps unmatched page at PFN fffc2a40
      [   68.585322] Modules linked in: igbvf ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat kvm_intel kvm igb megs
      [   68.599163] CPU: 2 PID: 1860 Comm: ifconfig Not tainted 4.2.0-rc4+ #147
      [   68.606543] Hardware name: IBM  -[546025Z]-/00Y7630, BIOS -[VVE134TUS-1.51]- 10/17/2013
      [   68.615473]  0000000000000dbd ffff88046441bb08 ffffffff81a5ad0b ffffffff81e2f9ea
      [   68.623775]  ffff88046441bb58 ffff88046441bb48 ffffffff81056b55 ffff88047fc583c0
      [   68.632075]  0000000000000000 ffff880469a8e600 00000000fffc2a40 ffff880465b32098
      [   68.640375] Call Trace:
      [   68.643109]  [<ffffffff81a5ad0b>] dump_stack+0x48/0x5d
      [   68.648844]  [<ffffffff81056b55>] warn_slowpath_common+0x95/0xe0
      [   68.655549]  [<ffffffff81056c56>] warn_slowpath_fmt+0x46/0x70
      [   68.661960]  [<ffffffff8158a614>] ? find_iova+0x54/0x90
      [   68.667791]  [<ffffffff815988dc>] intel_unmap+0x20c/0x220
      [   68.673815]  [<ffffffff8159891e>] intel_unmap_page+0xe/0x10
      [   68.680038]  [<ffffffffa0067536>] igbvf_clean_rx_ring+0x96/0x370 [igbvf]
      [   68.687516]  [<ffffffffa0067915>] igbvf_down+0x105/0x110 [igbvf]
      [   68.694219]  [<ffffffffa0067beb>] igbvf_change_mtu+0x16b/0x180 [igbvf]
      [...]
      Signed-off-by: NStefan Assmann <sassmann@kpanic.de>
      Acked-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      fae5ecae
  14. 21 3月, 2015 1 次提交
  15. 24 2月, 2015 2 次提交
  16. 31 1月, 2015 1 次提交
  17. 14 1月, 2015 1 次提交
  18. 13 8月, 2014 1 次提交
  19. 11 4月, 2014 1 次提交
  20. 20 3月, 2014 1 次提交
  21. 19 2月, 2014 1 次提交
  22. 01 1月, 2014 1 次提交
  23. 24 10月, 2013 2 次提交
  24. 22 9月, 2013 1 次提交
    • R
      DMA-API: net: intel/igbvf: fix 32-bit DMA mask handling · c21b8ebc
      Russell King 提交于
      The fallback to 32-bit DMA mask is rather odd:
      	err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
      	if (!err) {
      		err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
      		if (!err)
      			pci_using_dac = 1;
      	} else {
      		err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
      		if (err) {
      			err = dma_set_coherent_mask(&pdev->dev,
      						    DMA_BIT_MASK(32));
      			if (err) {
      				dev_err(&pdev->dev, "No usable DMA "
      					"configuration, aborting\n");
      				goto err_dma;
      			}
      		}
      	}
      This means we only set the coherent DMA mask in the fallback path if
      the DMA mask set failed, which is silly.  This fixes it to set the
      coherent DMA mask only if dma_set_mask() succeeded, and to error out
      if either fails.
      Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c21b8ebc
  25. 20 4月, 2013 3 次提交
  26. 18 3月, 2013 1 次提交
  27. 16 2月, 2013 1 次提交
  28. 05 2月, 2013 1 次提交
  29. 28 1月, 2013 1 次提交
  30. 09 1月, 2013 1 次提交
  31. 04 1月, 2013 1 次提交