1. 21 6月, 2017 1 次提交
  2. 13 6月, 2017 1 次提交
    • J
      i40e: fix handling of HW ATR eviction · 6964e53f
      Jacob Keller 提交于
      A recent commit to refactor the driver and remove the hw_disabled_flags
      field accidentally introduced two regressions. First, we overwrote
      pf->flags which removed various key flags including the MSI-X settings.
      
      Additionally, it was intended that we have now two flags,
      HW_ATR_EVICT_CAPABLE and HW_ATR_EVICT_ENABLED, but this was not done,
      and we accidentally were mis-using HW_ATR_EVICT_CAPABLE everywhere.
      
      This patch adds the missing piece, HW_ATR_EVICT_ENABLED, and safely
      updates pf->flags instead of overwriting it.
      
      Without this patch we will have many problems including disabling MSI-X
      support, and we'll attempt to use HW ATR eviction on devices which do
      not support it.
      
      Fixes: 47994c11 ("i40e: remove hw_disabled_flags in favor of using separate flag bits", 2017-04-19)
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6964e53f
  3. 31 5月, 2017 1 次提交
  4. 30 4月, 2017 3 次提交
    • J
      i40e: remove hw_disabled_flags in favor of using separate flag bits · 47994c11
      Jacob Keller 提交于
      The hw_disabled_flags field was added as a way of signifying that
      a feature was automatically or temporarily disabled. However, we
      actually only use this for FDir features. Replace its use with new
      _AUTO_DISABLED flags instead. This is more readable, because you aren't
      setting an *_ENABLED flag to *disable* the feature.
      
      Additionally, clean up a few areas where we used these bits. First, we
      don't really need to set the auto-disable flag for ATR if we're fully
      disabling the feature via ethtool.
      
      Second, we should always clear the auto-disable bits in case they somehow
      got set when the feature was disabled. However, avoid displaying
      a message that we've re-enabled the feature.
      
      Third, we shouldn't be re-enabling ATR in the SB ntuple add flow,
      because it might have been disabled due to space constraints. Instead,
      we should just wait for the fdir_check_and_reenable to be called by the
      watchdog.
      
      Overall, this change allows us to simplify some code by removing an
      extra field we didn't need, and the result should make it more clear as
      to what we're actually doing with these flags.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      47994c11
    • J
      i40e: use DECLARE_BITMAP for state fields · 0da36b97
      Jacob Keller 提交于
      Instead of assuming our flags fit within an unsigned long, use
      DECLARE_BITMAP which will ensure that we always allocate enough space.
      Additionally, use __I40E_STATE_SIZE__ markers as the last element of the
      enumeration so that the size of the BITMAP is compile-time assigned
      rather than programmer-time assigned. This ensures that potential future
      flag additions do not actually overrun the array. This is especially
      important as 32bit systems would only have 32bit longs instead of 64bit
      longs as we generally have assumed in the prior code.
      
      This change also removes a dereference of the state fields throughout
      the code, so it does have a bit of code churn. The conversions were
      automated using sed replacements with an alternation
      
        s/&(vsi->back|vsi|pf)->state/\1->state/
        s/&adapter->vsi.state/adapter->vsi.state/
      
      For debugfs, we modify the printing so that we can display chunks of the
      state value on new lines. This ensures that we can print the entire set
      of state values. Additionally, we now print them as 08lx to ensure that
      they display nicely.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0da36b97
    • J
      i40e: properly spell I40E_VF_STATE_* flags · 6322e63c
      Jacob Keller 提交于
      These flags represent the state of the VF at various times. Do not
      spell them as _STAT_ which can be confusing to readers who may think
      these refer to statistics.
      
      Change-ID: I6bc092cd472e8276896a1fd7498aced2084312df
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      6322e63c
  5. 20 4月, 2017 1 次提交
    • J
      i40e: fix CONFIG_BUSY checks in i40e_set_settings function · e8d2f4c6
      Jacob Keller 提交于
      The check for I40E_CONFIG_BUSY state bit in the i40e_set_link_ksettings
      function is fishy. First we can notice a few things about the check here.
      
      First a similar check was introduced by commit
      'c7d05ca8 ("i40e: driver ethtool core")'
      
      Later a commit introducing the link settings was added by commit
      'bf9c7141 ("i40e: Implement set_settings for ethtool")'
      
      However, this second check was against vsi->state instead of pf->state,
      and also failed to set the bit, it only checks. That indicates the locking
      was not quite correct. The only other place that the state bit
      in vsi->state gets used is to protect the filter list.
      
      Since this code does not care about the mac filter list,  and seems
      clear the original code should have set the pf->state bit. Fix these
      issues by using pf->state correctly, and by actually setting the bit
      so that we properly lock as expected.
      
      Since these checks occur while holding the rtnl_lock(), lets also add a
      timeout so that we don't potentially softlock the system.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      e8d2f4c6
  6. 08 4月, 2017 2 次提交
  7. 29 3月, 2017 2 次提交
  8. 28 3月, 2017 1 次提交
  9. 24 3月, 2017 7 次提交
    • J
      i40e: add support for SCTPv4 FDir filters · f223c875
      Jacob Keller 提交于
      Enable FDir filters for SCTPv4 packets using the ethtool ntuple
      interface to enable filters. The ethtool API does not allow masking on
      the verification tag.
      
      Change-Id: I093e88a8143994c7e6f4b7b17a0bd5cf861d18e4
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      f223c875
    • J
      i40e: implement support for flexible word payload · 0e588de1
      Jacob Keller 提交于
      Add support for flexible payloads passed via ethtool user-def field.
      This support is somewhat limited due to hardware design. The input set
      can only be programmed once per filter type, and the flexible offset is
      part of this filter input set. This means that the user cannot program
      both a regular and a flexible filter at the same time for a given flow
      type. Additionally, the user may not program two flexible filters of the
      same flow type with different offsets, although they are allowed to
      configure different values at that offset location.
      
      We support a single flexible word (2byte) value per protocol type, and
      we handle the FLX_PIT register using a list of flexible entries so that
      each flow type may be configured separately.
      
      Due to hardware implementation, the flexible data is offset from the
      start of the packet payload, and thus may not be in part of the header
      data. For this reason, the offset provided by the user defined data is
      interpreted as a byte offset from the start of the matching payload.
      Previous implementations have tried to represent the offset as from the
      start of the frame, but this is not feasible because header sizes may
      change due to options.
      
      Change-Id: 36ed27995e97de63f9aea5ade5778ff038d6f811
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0e588de1
    • J
      i40e: add parsing of flexible filter fields from userdef · e793095e
      Jacob Keller 提交于
      Add code to parse the user-def field into a data structure format. This
      code is intended to allow future extensions of the user-def field by
      keeping all code that actually reads and writes the field into a single
      location. This ensures that we do not litter the driver with references
      to the user-def field and minimizes the amount of bitwise operations we
      need to do on the data.
      
      Add code which parses the lower 32bits into a flexible word and its
      offset. This will be used in a future patch to enable flexible filters
      which can match on some arbitrary data in the packet payload. For now,
      we just return -EOPNOTSUPP when this is used.
      
      Add code to fill in the user-def field when reporting the filter back,
      even though we don't actually implement any user-def fields yet.
      
      Additionally, ensure that we mask the extended FLOW_EXT bit from the
      flow_type now that we will be accepting filters which have the FLOW_EXT
      bit set (and thus make use of the user-def field).
      
      Change-Id: I238845035c179380a347baa8db8223304f5f6dd7
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      e793095e
    • J
      i40e: partition the ring_cookie to get VF index · 43b15697
      Jacob Keller 提交于
      Do not use the user-def field for determining the VF target. Instead,
      similar to ixgbe, partition the ring_cookie value into 8bits of VF
      index, along with 32bits of queue number. This is better than using the
      user-def field, because it leaves the field open for extension in
      a future patch which will enable flexible data. Also, this matches with
      convention used by ixgbe and other drivers.
      
      Change-Id: Ie36745186d817216b12f0313b99ec95cb8a9130c
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      43b15697
    • J
      i40e: allow changing input set for ntuple filters · 9229e993
      Jacob Keller 提交于
      Add support to detect when we can update the input set for each flow
      type.
      
      Because the hardware only supports a single input set for all flows of
      that matching type, the driver shall only allow the input set to change
      if there are no other configured filters for that flow type.
      
      Thus, the first filter added for each flow type is allowed to change the
      input set, and all future filters must match the same input set. Display
      a diagnostic message whenever the filter input set changes, and
      a warning whenever a filter cannot be accepted because it does not match
      the configured input set.
      
      Change-Id: Ic22e1c267ae37518bb036aca4a5694681449f283
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      9229e993
    • J
      i40e: check current configured input set when adding ntuple filters · 36777d9f
      Jacob Keller 提交于
      Do not assume that hardware has been programmed with the default mask,
      but instead read the input set registers to determine what is currently
      programmed. This ensures that all programmed filters match exactly how
      the hardware will interpret them, avoiding confusion regarding filter
      behavior.
      
      This sets the initial ground-work for allowing custom input sets where
      some fields are disabled. A future patch will fully implement this
      feature.
      
      Instead of using bitwise negation, we'll just explicitly check for the
      correct value. The use of htonl and htons are used to silence sparse
      warnings. The compiler should be able to handle the constant value and
      avoid actually performing a byteswap.
      
      Change-Id: I3d8db46cb28ea0afdaac8c5b31a2bfb90e3a4102
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      36777d9f
    • J
      i40e: correctly honor the mask fields for ETHTOOL_SRXCLSRLINS · faa16e0f
      Jacob Keller 提交于
      The current implementation of .set_rxnfc does not properly read the mask
      field for filter entries. This results in incorrect driver behavior, as
      we do not reject filters which have masks set to ignore some fields. The
      current implementation simply assumes that every part of the tuple or
      "input set" is specified. This results in filters not behaving as
      expected, and not working correctly.
      
      As a first step in supporting some partial filters, add code which
      checks the mask fields and rejects any filters which do not have an
      acceptable mask. For now, we just assume that all fields must be set.
      
      This will get the driver one step towards allowing some partial filters.
      At a minimum, the ethtool commands which previously installed filters
      that would not function will now return a non-zero exit code indicating
      failure instead.
      
      We should now be meeting the minimum requirements of the .set_rxnfc API,
      by ensuring that all filters we program have a valid mask value for each
      field.
      
      Finally, add code to report the mask correctly so that the ethtool
      command properly reports the mask to the user.
      
      Note that the typecast to (__be16) when checking source and destination
      port masks is required because the ~ bitwise negation operator does not
      correctly handle variables other than integer size.
      
      Change-Id: Ia020149e07c87aa3fcec7b2283621b887ef0546f
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      faa16e0f
  10. 21 3月, 2017 4 次提交
  11. 18 3月, 2017 1 次提交
  12. 15 3月, 2017 2 次提交
  13. 12 2月, 2017 1 次提交
  14. 03 2月, 2017 2 次提交
    • A
      i40e: add interrupt rate limit verbosity · 33084060
      Alan Brady 提交于
      Due to the resolution of the register controlling interrupt rate
      limiting, setting certain values for the interrupt rate limit make it
      appear as though the limiting is not completely accurate.  The problem
      is that the interrupt rate limit is getting rounded down to the nearest
      multiple of 4.  This patch fixes the problem by adding some feedback to
      the user as to the actual interrupt rate limit being used when it
      differs from the requested limit.  Without this patch setting interrupt
      rate limits may appear to behave inaccurately.
      
      Change-ID: I3093cf3f2d437d35a4c4f4bb5af5ce1b85ab21b7
      Signed-off-by: NAlan Brady <alan.brady@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      33084060
    • A
      i40e: refactor macro INTRL_USEC_TO_REG · 1c0e6a36
      Alan Brady 提交于
      This patch refactors the macro INTRL_USEC_TO_REG into a static inline
      function and fixes a couple subtle bugs caused by the macro.
      
      This patch fixes a bug which was caused by passing a bad register value
      to the firmware.  If enabling interrupt rate limiting, a non-zero value
      for the rate limit must be used.  Otherwise the firmware sets the
      interrupt rate limit to the maximum value.  Due to the limited
      resolution of the register, attempting to set a value of 1, 2, or 3
      would be rounded down to 0 and limiting was left enabled, causing
      unexpected behavior.
      
      This patch also fixes a possible bug in which using the macro itself can
      introduce unintended side-affects because the macro argument is used
      more than once in the macro definition (e.g. a variable post-increment
      argument would perform a double increment on the variable).
      
      Without this patch, attempting to set interrupt rate limits of 1, 2, or
      3 results in unexpected behavior and future use of this macro could
      cause subtle bugs.
      
      Change-Id: I83ac842de0ca9c86761923d6e3a4d7b1b95f2b3f
      Signed-off-by: NAlan Brady <alan.brady@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      1c0e6a36
  15. 07 12月, 2016 3 次提交
  16. 03 12月, 2016 4 次提交
    • J
      i40e/i40evf: replace for memcpy with single memcpy call in ethtool · e5d32205
      Jacob Keller 提交于
      memcpy replaced with single memcpy call in ethtool.
      
      Change-ID: I3f5bef6bcc593412c56592c6459784db41575a0a
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      e5d32205
    • H
      i40e: Fix for ethtool Supported link modes · 4ad9f4f9
      Harshitha Ramamurthy 提交于
      This patch fixes the problem where the ethtool Supported link
      modes list backplane interfaces on X722 devices for 10GbE with
      SFP+ and Cortina retimer. This patch fixes the problem by setting
      and using a flag for this particular device since the backplane
      interface is only between the internal PHY and the retimer and it
      should not be seen by the user as they cannot use it.
      Without this patch, the user wrongly thinks that backplane interfaces
      are supported on their device when they actually are not.
      
      Change-ID: I3882bc2928431d48a2db03a51a713a1f681a79e9
      Signed-off-by: NHarshitha Ramamurthy <harshitha.ramamurthy@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4ad9f4f9
    • T
      i40e: fix panic on SPARC while changing num of desc · 2f7679ee
      Tushar Dave 提交于
      On SPARC, writel() should not be used to write directly to memory
      address but only to memory mapped I/O address otherwise it causes
      data access exception.
      
      Commit 147e81ec ("i40e: Test memory before ethtool alloc
      succeeds") introduced a code that uses memory address to fake the HW
      tail address and attempt to write to that address using writel()
      causes kernel panic on SPARC. The issue is reproduced while changing
      number of descriptors using ethtool.
      
      This change resolves the panic by using HW read-only memory mapped
      I/O register to fake HW tail address instead memory address.
      
      e.g.
      > ethtool -G eth2 tx 2048 rx 2048
      i40e 0000:03:00.2 eth2: Changing Tx descriptor count from 512 to 2048.
      i40e 0000:03:00.2 eth2: Changing Rx descriptor count from 512 to 2048
      sun4v_data_access_exception: ADDR[fff8001f9734a000] CTX[0000]
      TYPE[0004], going.
                    \|/ ____ \|/
                    "@'/ .. \`@"
                    /_| \__/ |_\
                       \__U_/
      ethtool(3273): Dax [#1]
      CPU: 9 PID: 3273 Comm: ethtool Tainted: G            E
      4.8.0-linux-net_temp+ #7
      task: fff8001f96d7a660 task.stack: fff8001f97348000
      TSTATE: 0000009911001601 TPC: 00000000103189e4 TNPC: 00000000103189e8 Y:
      00000000    Tainted: G            E
      TPC: <i40e_alloc_rx_buffers+0x124/0x260 [i40e]>
      g0: fff8001f4eb64000 g1: 00000000000007ff g2: fff8001f9734b92c g3:
      00203e0000000000
      g4: fff8001f96d7a660 g5: fff8001fa6704000 g6: fff8001f97348000 g7:
      0000000000000001
      o0: 0006000046706928 o1: 00000000db3e2000 o2: fff8001f00000000 o3:
      0000000000002000
      o4: 0000000000002000 o5: 0000000000000001 sp: fff8001f9734afc1 ret_pc:
      0000000010318a64
      RPC: <i40e_alloc_rx_buffers+0x1a4/0x260 [i40e]>
      l0: fff8001f4e8bffe0 l1: fff8001f4e8cffe0 l2: 00000000000007ff l3:
      00000000ff000000
      l4: 0000000000ff0000 l5: 000000000000ff00 l6: 0000000000cda6a8 l7:
      0000000000e822f0
      i0: fff8001f96380000 i1: 0000000000000000 i2: 00203edb00000000 i3:
      0006000046706928
      i4: 0000000002086320 i5: 0000000000e82370 i6: fff8001f9734b071 i7:
      00000000103062d4
      I7: <i40e_set_ringparam+0x3b4/0x540 [i40e]>
      Call Trace:
       [00000000103062d4] i40e_set_ringparam+0x3b4/0x540 [i40e]
       [000000000094e2f8] dev_ethtool+0x898/0xbe0
       [0000000000965570] dev_ioctl+0x250/0x300
       [0000000000923800] sock_do_ioctl+0x40/0x60
       [000000000092427c] sock_ioctl+0x7c/0x280
       [00000000005ef040] vfs_ioctl+0x20/0x60
       [00000000005ef5d4] do_vfs_ioctl+0x194/0x4c0
       [00000000005ef974] SyS_ioctl+0x74/0xa0
       [0000000000406214] linux_sparc_syscall+0x34/0x44
      Disabling lock debugging due to kernel taint
      Caller[00000000103062d4]: i40e_set_ringparam+0x3b4/0x540 [i40e]
      Caller[000000000094e2f8]: dev_ethtool+0x898/0xbe0
      Caller[0000000000965570]: dev_ioctl+0x250/0x300
      Caller[0000000000923800]: sock_do_ioctl+0x40/0x60
      Caller[000000000092427c]: sock_ioctl+0x7c/0x280
      Caller[00000000005ef040]: vfs_ioctl+0x20/0x60
      Caller[00000000005ef5d4]: do_vfs_ioctl+0x194/0x4c0
      Caller[00000000005ef974]: SyS_ioctl+0x74/0xa0
      Caller[0000000000406214]: linux_sparc_syscall+0x34/0x44
      Caller[0000000000107154]: 0x107154
      Instruction DUMP: e43620c8
       e436204a  c45e2038
      <c2a083a0> 82102000
       81cfe008  90086001
       82102000  81cfe008
      
      Kernel panic - not syncing: Fatal exception
      Signed-off-by: NTushar Dave <tushar.n.dave@oracle.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      2f7679ee
    • J
      i40e: avoid duplicate private flags definitions · d182a5ca
      Jacob Keller 提交于
      Separate the global private flags and the regular private flags per
      interface into two arrays. Future additions of private flags will not
      need to be duplicated which may lead to buggy code. Also rename
      "i40e_priv_flags_strings_gl" to "i40e_gl_priv_flags_strings" for
      clarity, as it reads more naturally.
      
      Change-ID: I68caef3c9954eb7da342d7f9d20f2873186f2758
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      d182a5ca
  17. 01 11月, 2016 2 次提交
  18. 29 10月, 2016 2 次提交
    • A
      i40e: Clean up handling of msglevel flags and debug parameter · 5d4ca23e
      Alexander Duyck 提交于
      So the i40e driver had a really convoluted configuration for how to handle
      the debug flags contained in msg_level.  Part of the issue is that the
      driver has its own 32 bit mask that it was using to track a separate set of
      debug features.  From what I can tell it was trying to use the upper 4 bits
      to determine if the value was meant to represent a bit-mask or the numeric
      value provided by debug level.
      
      What this patch does is clean this up by compressing those 4 bits into bit
      31, as a result we just have to perform a check against the value being
      negative to determine if we are looking at a debug level (positive), or a
      debug mask (negative).  The debug level will populate the msg_level, and
      the debug mask will populate the debug_mask in the hardware struct.
      
      I added similar logic for ethtool.  If the value being provided has bit 31
      set we assume the value being provided is a debug mask, otherwise we assume
      it is a msg_enable mask.  For displaying we only provide the msg_enable,
      and if debug_mask is in use we will print it to the dmesg log.
      
      Lastly I removed the debugfs interface.  It is redundant with what we
      already have in ethtool and really doesn't belong anyway.
      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>
      5d4ca23e
    • J
      i40e: Make struct i40e_stats const · fe180a5e
      Joe Perches 提交于
      Move some data to text
      
      $ size drivers/net/ethernet/intel/i40e/i40e_ethtool.o*
         text	   data	    bss	    dec	    hex	filename
        25012	      0	     32	  25044	   61d4	drivers/net/ethernet/intel/i40e/i40e_ethtool.o.new
        22868	   2120	     32	  25020	   61bc	drivers/net/ethernet/intel/i40e/i40e_ethtool.o.old
      Signed-off-by: NJoe Perches <joe@perches.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      fe180a5e