1. 31 5月, 2017 2 次提交
    • L
      ixgbe: initialize u64_stats_sync structures early at ixgbe_probe · b09457e7
      Liwei Song 提交于
      Fix the following CallTrace:
      INFO: trying to register non-static key.
      the code is fine but needs lockdep annotation.
      turning off the locking correctness validator.
      CPU: 71 PID: 1 Comm: swapper/0 Not tainted 4.8.8-WR9.0.0.1_standard #11
      Hardware name: Intel Corporation S2600WTT/S2600WTT,
      BIOS GRNDSDP1.86B.0036.R05.1407140519 07/14/2014
       00200086 00200086 eb5e1ab8 c144dd70 00000000 00000000 eb5e1af8 c10af89a
       c1d23de4 eb5e1af8 00000009 eb5d8600 eb5d8638 eb5e1af8 c10b14d8 00000009
       0000000a c1d32911 00000000 00000000 e44c826c eb5d8000 eb5e1b74 c10b214e
      Call Trace:
       [<c144dd70>] dump_stack+0x5f/0x8f
       [<c10af89a>] register_lock_class+0x25a/0x4c0
       [<c10b14d8>] ? check_irq_usage+0x88/0xc0
       [<c10b214e>] __lock_acquire+0x5e/0x17a0
       [<c1abdb9b>] ? _raw_spin_unlock_irqrestore+0x3b/0x70
       [<c10cf14a>] ? rcu_read_lock_sched_held+0x8a/0x90
       [<c10b3c5f>] lock_acquire+0x9f/0x1f0
       [<c1922dcf>] ? dev_get_stats+0x5f/0x110
       [<c176e6b3>] ixgbe_get_stats64+0x113/0x320
       [<c1922dcf>] ? dev_get_stats+0x5f/0x110
       [<c1922dcf>] dev_get_stats+0x5f/0x110
       [<c1ab5415>] rtnl_fill_stats+0x40/0x105
       [<c193dd45>] rtnl_fill_ifinfo+0x4c5/0xd20
       [<c11c5115>] ? __kmalloc_node_track_caller+0x1a5/0x410
       [<c1917487>] ? __kmalloc_reserve.isra.42+0x27/0x80
       [<c191754f>] ? __alloc_skb+0x6f/0x270
       [<c1942291>] rtmsg_ifinfo_build_skb+0x71/0xd0
       [<c194230a>] rtmsg_ifinfo.part.23+0x1a/0x50
       [<c1923dad>] ? call_netdevice_notifiers_info+0x2d/0x60
       [<c194236b>] rtmsg_ifinfo+0x2b/0x40
       [<c192f997>] register_netdevice+0x3d7/0x4d0
       [<c192faa7>] register_netdev+0x17/0x30
       [<c177b83d>] ixgbe_probe+0x118d/0x1610
       [<c1498202>] local_pci_probe+0x32/0x80
       [<c1498172>] ? pci_match_device+0xd2/0x100
       [<c14991e0>] pci_device_probe+0xc0/0x110
       [<c1652cc5>] driver_probe_device+0x1c5/0x280
       [<c1498172>] ? pci_match_device+0xd2/0x100
       [<c1652e09>] __driver_attach+0x89/0x90
       [<c1652d80>] ? driver_probe_device+0x280/0x280
       [<c165114f>] bus_for_each_dev+0x4f/0x80
       [<c165269e>] driver_attach+0x1e/0x20
       [<c1652d80>] ? driver_probe_device+0x280/0x280
       [<c1652317>] bus_add_driver+0x1a7/0x220
       [<c1653a79>] driver_register+0x59/0xe0
       [<c1f897b8>] ? igb_init_module+0x49/0x49
       [<c1497b2a>] __pci_register_driver+0x4a/0x50
       [<c1f8985d>] ixgbe_init_module+0xa5/0xc4
       [<c1000485>] do_one_initcall+0x35/0x150
       [<c107e818>] ? parameq+0x18/0x70
       [<c1f395d8>] ? repair_env_string+0x12/0x51
       [<c107ead0>] ? parse_args+0x260/0x3b0
       [<c1074f73>] ? __usermodehelper_set_disable_depth+0x43/0x50
       [<c1f39e90>] kernel_init_freeable+0x19b/0x267
       [<c1f395c6>] ? set_debug_rodata+0xf/0xf
       [<c10b1e7b>] ? trace_hardirqs_on+0xb/0x10
       [<c1abdc02>] ? _raw_spin_unlock_irq+0x32/0x50
       [<c1085f0b>] ? finish_task_switch+0xab/0x1f0
       [<c1085ec9>] ? finish_task_switch+0x69/0x1f0
       [<c1ab6a30>] kernel_init+0x10/0x110
       [<c108bd65>] ? schedule_tail+0x25/0x80
       [<c1abe422>] ret_from_kernel_thread+0xe/0x24
       [<c1ab6a20>] ? rest_init+0x130/0x130
      
      This CallTrace occurred on 32-bit kernel with CONFIG_PROVE_LOCKING
      enabled.
      
      This happens at ixgbe driver probe hardware stage, when comes to
      ixgbe_get_stats64, the seqcount/seqlock still not initialize, although
      this was initialize in TX/RX resources setup routin, but it was too late,
      then lockdep give this Warning.
      
      To fix this, move the u64_stats_init function to driver probe stage,
      which before we get the status of seqcount and after the RX/TX ring
      was finished init.
      Signed-off-by: NLiwei Song <liwei.song@windriver.com>
      Tested-by: NKrishneil Singh  <krishneil.k.singh@intel.com>
      b09457e7
    • S
      ixgbe/ixgbevf: Enables TSO for MPLS encapsulated packets · 2a20525b
      Scott Peterson 提交于
      This patch advertises TSO & GSO features in netdev->mpls_features.
      In ixgbe(vf)_tso() where we set up segmentation offload, the IP
      header will be the inner network header when eth_p_mpls() indicates
      the Ethernet protocol is MPLS (UC or MC).
      Suggested-by: NAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: NScott Peterson <scott.d.peterson@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      2a20525b
  2. 30 4月, 2017 5 次提交
  3. 28 4月, 2017 1 次提交
  4. 19 4月, 2017 5 次提交
  5. 18 3月, 2017 1 次提交
  6. 16 3月, 2017 1 次提交
    • A
      mqprio: Modify mqprio to pass user parameters via ndo_setup_tc. · 56f36acd
      Amritha Nambiar 提交于
      The configurable priority to traffic class mapping and the user specified
      queue ranges are used to configure the traffic class, overriding the
      hardware defaults when the 'hw' option is set to 0. However, when the 'hw'
      option is non-zero, the hardware QOS defaults are used.
      
      This patch makes it so that we can pass the data the user provided to
      ndo_setup_tc. This allows us to pull in the queue configuration if the
      user requested it as well as any additional hardware offload type
      requested by using a value other than 1 for the hw value.
      
      Finally it also provides a means for the device driver to return the level
      supported for the offload type via the qopt->hw value. Previously we were
      just always assuming the value to be 1, in the future values beyond just 1
      may be supported.
      Signed-off-by: NAmritha Nambiar <amritha.nambiar@intel.com>
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      56f36acd
  7. 03 3月, 2017 2 次提交
    • A
      ixgbe: Limit use of 2K buffers on architectures with 256B or larger cache lines · c74042f3
      Alexander Duyck 提交于
      On architectures that have a cache line size larger than 64 Bytes we start
      running into issues where the amount of headroom for the frame starts
      shrinking.
      
      The size of skb_shared_info on a system with a 64B L1 cache line size is
      320.  This increases to 384 with a 128B cache line, and 512 with a 256B
      cache line.
      
      In addition the NET_SKB_PAD value increases as well consistent with the
      cache line size.  As a result when we get to a 256B cache line as seen on
      the s390 we end up 768 bytes used by padding and shared info leaving us
      with only 1280 bytes to use for data storage.  On architectures such as
      this we should default to using 3K Rx buffers out of a 8K page instead of
      trying to do 1.5K buffers out of a 4K page.
      
      To take all of this into account I have added one small check so that we
      compare the max_frame to the amount of actual data we can store.  This was
      already occurring for igb, but I had overlooked it for ixgbe as it doesn't
      have strict limits for 82599 once we enable jumbo frames.  By adding this
      check we will automatically enable 3K Rx buffers as soon as the maximum
      frame size we can handle drops below the standard Ethernet MTU.
      
      I also went through and fixed one small typo that I found where I had left
      an IGB in a variable name due to a copy/paste error.
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c74042f3
    • P
      ixgbe: update the rss key on h/w, when ethtool ask for it · d3aa9c9f
      Paolo Abeni 提交于
      Currently ixgbe_set_rxfh() updates the rss_key copy in the driver
      memory, but does not push the new value into the h/w. This commit
      add a new helper for the latter operation and call it in
      ixgbe_set_rxfh(), so that the h/w rss key value can be really
      updated via ethtool.
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      d3aa9c9f
  8. 16 2月, 2017 12 次提交
  9. 04 2月, 2017 1 次提交
  10. 19 1月, 2017 1 次提交
    • T
      net: Remove usage of net_device last_rx member · 4a7c9726
      Tobias Klauser 提交于
      The network stack no longer uses the last_rx member of struct net_device
      since the bonding driver switched to use its own private last_rx in
      commit 9f242738 ("bonding: use last_arp_rx in slave_last_rx()").
      
      However, some drivers still (ab)use the field for their own purposes and
      some driver just update it without actually using it.
      
      Previously, there was an accompanying comment for the last_rx member
      added in commit 4dc89133 ("net: add a comment on netdev->last_rx")
      which asked drivers not to update is, unless really needed. However,
      this commend was removed in commit f8ff080d ("bonding: remove
      useless updating of slave->dev->last_rx"), so some drivers added later
      on still did update last_rx.
      
      Remove all usage of last_rx and switch three drivers (sky2, atp and
      smc91c92_cs) which actually read and write it to use their own private
      copy in netdev_priv.
      
      Compile-tested with allyesconfig and allmodconfig on x86 and arm.
      
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Jay Vosburgh <j.vosburgh@gmail.com>
      Cc: Veaceslav Falico <vfalico@gmail.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Cc: Mirko Lindner <mlindner@marvell.com>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Reviewed-by: NJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a7c9726
  11. 09 1月, 2017 1 次提交
  12. 04 1月, 2017 4 次提交
  13. 02 12月, 2016 1 次提交
  14. 05 11月, 2016 3 次提交