1. 15 1月, 2014 3 次提交
  2. 11 1月, 2014 1 次提交
    • J
      net: core: explicitly select a txq before doing l2 forwarding · f663dd9a
      Jason Wang 提交于
      Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit(). The
      will cause several issues:
      
      - NETIF_F_LLTX were removed for macvlan, so txq lock were done for macvlan
        instead of lower device which misses the necessary txq synchronization for
        lower device such as txq stopping or frozen required by dev watchdog or
        control path.
      - dev_hard_start_xmit() was called with NULL txq which bypasses the net device
        watchdog.
      - dev_hard_start_xmit() does not check txq everywhere which will lead a crash
        when tso is disabled for lower device.
      
      Fix this by explicitly introducing a new param for .ndo_select_queue() for just
      selecting queues in the case of l2 forwarding offload. netdev_pick_tx() was also
      extended to accept this parameter and dev_queue_xmit_accel() was used to do l2
      forwarding transmission.
      
      With this fixes, NETIF_F_LLTX could be preserved for macvlan and there's no need
      to check txq against NULL in dev_hard_start_xmit(). Also there's no need to keep
      a dedicated ndo_dfwd_start_xmit() and we can just reuse the code of
      dev_queue_xmit() to do the transmission.
      
      In the future, it was also required for macvtap l2 forwarding support since it
      provides a necessary synchronization method.
      
      Cc: John Fastabend <john.r.fastabend@intel.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: e1000-devel@lists.sourceforge.net
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Acked-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f663dd9a
  3. 30 11月, 2013 2 次提交
  4. 11 11月, 2013 1 次提交
  5. 09 11月, 2013 2 次提交
  6. 08 11月, 2013 1 次提交
  7. 06 11月, 2013 1 次提交
    • J
      net: Explicitly initialize u64_stats_sync structures for lockdep · 827da44c
      John Stultz 提交于
      In order to enable lockdep on seqcount/seqlock structures, we
      must explicitly initialize any locks.
      
      The u64_stats_sync structure, uses a seqcount, and thus we need
      to introduce a u64_stats_init() function and use it to initialize
      the structure.
      
      This unfortunately adds a lot of fairly trivial initialization code
      to a number of drivers. But the benefit of ensuring correctness makes
      this worth while.
      
      Because these changes are required for lockdep to be enabled, and the
      changes are quite trivial, I've not yet split this patch out into 30-some
      separate patches, as I figured it would be better to get the various
      maintainers thoughts on how to best merge this change along with
      the seqcount lockdep enablement.
      
      Feedback would be appreciated!
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Acked-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Cc: James Morris <jmorris@namei.org>
      Cc: Jesse Gross <jesse@nicira.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Cc: Mirko Lindner <mlindner@marvell.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Roger Luethi <rl@hellgate.ch>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Simon Horman <horms@verge.net.au>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Wensong Zhang <wensong@linux-vs.org>
      Cc: netdev@vger.kernel.org
      Link: http://lkml.kernel.org/r/1381186321-4906-2-git-send-email-john.stultz@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      827da44c
  8. 01 11月, 2013 1 次提交
  9. 29 10月, 2013 3 次提交
  10. 24 10月, 2013 2 次提交
  11. 02 10月, 2013 1 次提交
  12. 22 9月, 2013 1 次提交
    • R
      DMA-API: net: intel/ixgbe: fix 32-bit DMA mask handling · f5f2eda8
      Russell King 提交于
      The fallback to 32-bit DMA mask is rather odd:
      	if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
      	    !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
      		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;
      			}
      		}
      		pci_using_dac = 0;
      	}
      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>
      f5f2eda8
  13. 14 9月, 2013 1 次提交
  14. 13 9月, 2013 1 次提交
  15. 29 8月, 2013 3 次提交
  16. 02 8月, 2013 1 次提交
  17. 31 7月, 2013 7 次提交
  18. 11 7月, 2013 1 次提交
  19. 11 6月, 2013 2 次提交
  20. 26 4月, 2013 1 次提交
    • J
      ixgbe: fix EICR write in ixgbe_msix_other · d87d8307
      Jacob Keller 提交于
      Previously, the ixgbe_msix_other was writing the full 32bits of the set
      interrupts, instead of only the ones which the ixgbe_msix_other is
      handling. This resulted in a loss of performance when the X540's PPS feature is
      enabled due to sometimes clearing queue interrupts which resulted in the driver
      not getting the interrupt for cleaning the q_vector rings often enough. The fix
      is to simply mask the lower 16bits off so that this handler does not write them
      in the EICR, which causes them to remain high and be properly handled by the
      clean_rings interrupt routine as normal.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Cc: stable <stable@vger.kernel.org>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      d87d8307
  21. 25 4月, 2013 4 次提交