1. 08 10月, 2017 9 次提交
  2. 07 10月, 2017 25 次提交
  3. 06 10月, 2017 6 次提交
    • J
      i40e/i40evf: organize and re-number feature flags · b74f571f
      Jacob Keller 提交于
      Now that we've reduced the number of flags, organize similar flags
      together and re-number them accordingly.
      
      Since we don't yet have more than 32 flags, we'll use a u32 for both the
      hw_features and flag field. Should we gain more flags in the future, we
      may need to convert to a u64 or separate flags out into two fields.
      
      One alternative approach considered, but not implemented here, was to
      use an enumeration for the flag variables, and create a macro
      I40E_FLAG() which used string concatenation to generate BIT_ULL values.
      This has the advantage of making the actual bit values compile-time
      dynamic so that we do not need to worry about matching the order to the
      bit value. However, this does produce a high level of code churn, and
      makes it more difficult to read a dumped flags value when debugging.
      
      Change-ID: I8653fff69453cd547d6fe98d29dfa9d8710387d1
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NMitch Williams <mitch.a.williams@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      b74f571f
    • J
      i40e: ignore skb->xmit_more when deciding to set RS bit · a5340d93
      Jacob Keller 提交于
      Since commit 6a7fded7 ("i40e: Fix RS bit update in Tx path and
      disable force WB workaround") we've tried to "optimize" setting the
      RS bit based around skb->xmit_more. This same logic was refactored
      in commit 1dc8b538 ("i40e: Reorder logic for coalescing RS bits"),
      but ultimately was not functionally changed.
      
      Using skb->xmit_more in this way is incorrect, because in certain
      circumstances we may see a large number of skbs in sequence with
      xmit_more set. This leads to a performance loss as the hardware does not
      writeback anything for those packets, which delays the time it takes for
      us to respond to the stack transmit requests. This significantly impacts
      UDP performance, especially when layered with multiple devices, such as
      bonding, VLANs, and vnet setups.
      
      This was not noticed until now because it is difficult to create a setup
      which reproduces the issue. It was discovered in a UDP_STREAM test in
      a VM, connected using a vnet device to a bridge, which is connected to
      a bonded pair of X710 ports in active-backup mode with a VLAN. These
      layered devices seem to compound the number of skbs transmitted at once
      by the qdisc. Additionally, the problem can be masked by reducing the
      ITR value.
      
      Since the original commit does not provide strong justification for this
      RS bit "optimization", revert to the previous behavior of setting the RS
      bit every 4th packet.
      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>
      a5340d93
    • J
      i40evf: enable support for VF VLAN tag stripping control · 0a3b4f70
      Jacob Keller 提交于
      A recent commit 809481484e5d ("i40e/i40evf: support for VF VLAN tag
      stripping control") added support for VFs to negotiate the control of
      VLAN tag stripping. This should have allowed VFs to disable the feature.
      Unfortunately, the flag was set only in netdev->feature flags and not in
      netdev->hw_features.
      
      This ultimately causes the stack to assume that it cannot change the
      flag, so it was unchangeable and marked as [fixed] in the ethtool -k
      output.
      
      Fix this by setting the feature in hw_features first, just as we do for
      the PF code. This enables ethtool -K to disable the feature correctly,
      and fully enables user control of the VLAN tag stripping feature.
      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>
      0a3b4f70
    • M
      i40e: do not enter PHY debug mode while setting LEDs behaviour · 052b93d0
      Mariusz Stachura 提交于
      Previous implementation of LED set/get functions required to enter
      PHY debug mode, in order to prevent access to it from FW and SW at
      the same time. Reset of all ports was a unwanted side effect.
      Signed-off-by: NMariusz Stachura <mariusz.stachura@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      052b93d0
    • A
      i40e: implement split PCI error reset handler · 19b7960b
      Alan Brady 提交于
      This patch implements the PCI error handler reset_prepare and reset_done.
      This allows us to handle function level reset.  Without this patch we
      are unable to perform and recover from an FLR correctly and this will cause
      VFs to be unable to recover from an FLR on the PF.
      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>
      19b7960b
    • F
      i40e: Properly maintain flow director filters list · 013df598
      Filip Sadowski 提交于
      When there is no space for more flow director filters and user requested to
      add a new one it is rejected by firmware and automatically removed from the
      filter list maintained by driver. This behaviour is correct. Afterwards
      existing filter can be removed making free slot for the new one. This
      however causes the newly added filter to be accepted by firmware but
      removed from driver filter list resulting in not showing after issuing
      'ethtool -n <dev_name>'.
      
      This happened due to not clearing the variable pf->fd_inv which stores
      filter number to be removed from the list when firmware refused to add the
      requested filter. It caused the filter with this specific ID to be
      constantly removed once it was added to the list although it has been
      accepted by firmware and effectively applied to the NIC.
      It was fixed by clearing pf->fd_inv variable after removal of the filter
      from the list when it was rejected by firmware.
      Signed-off-by: NFilip Sadowski <filip.sadowski@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      013df598