1. 19 3月, 2019 1 次提交
  2. 13 2月, 2019 2 次提交
  3. 13 1月, 2019 1 次提交
  4. 08 12月, 2018 1 次提交
  5. 27 11月, 2018 1 次提交
  6. 24 8月, 2018 1 次提交
  7. 08 8月, 2018 1 次提交
  8. 07 8月, 2018 2 次提交
  9. 14 7月, 2018 1 次提交
  10. 26 6月, 2018 1 次提交
  11. 25 6月, 2018 1 次提交
  12. 23 6月, 2018 1 次提交
  13. 05 6月, 2018 1 次提交
  14. 14 5月, 2018 2 次提交
  15. 01 5月, 2018 4 次提交
  16. 28 4月, 2018 1 次提交
  17. 27 3月, 2018 7 次提交
  18. 24 3月, 2018 1 次提交
  19. 20 3月, 2018 1 次提交
  20. 15 3月, 2018 4 次提交
  21. 27 2月, 2018 1 次提交
  22. 15 2月, 2018 1 次提交
    • A
      i40e: Add and delete cloud filter · e284fc28
      Avinash Dayanand 提交于
      This patch provides support to add or delete cloud filter for queue
      channels created for ADq on VF.
      We are using the HW's cloud filter feature and programming it to act
      as a TC filter applied to a group of queues.
      
      There are two possible modes for a VF when applying a cloud filter
      1. Basic Mode:	Intended to apply filters that don't need a VF to be
      		Trusted. This would include the following
      		  Dest MAC + L4 port
      		  Dest MAC + VLAN + L4 port
      2. Advanced Mode: This mode is only for filters with combination that
      		  requires VF to be Trusted.
      		  Dest IP + L4 port
      
      When cloud filters are applied on a trusted VF and for some reason
      the same VF is later made as untrusted then all cloud filters
      will be deleted. All cloud filters has to be re-applied in
      such a case.
      Cloud filters are also deleted when queue channel is deleted.
      
      Testing-Hints:
      =============
      1. Adding Basic Mode filter should be possible on a VF in
         Non-Trusted mode.
      2. In Advanced mode all filters should be able to be created.
      
      Steps:
      ======
      1. Enable ADq and create TCs using TC mqprio command
      2. Apply cloud filter.
      3. Turn-off the spoof check.
      4. Pass traffic.
      
      Example:
      ========
      1. tc qdisc add dev enp4s2 root mqprio num_tc 4 map 0 0 0 0 1 2 2 3\
      	queues 2@0 2@2 1@4 1@5 hw 1 mode channel
      2. tc qdisc add dev enp4s2 ingress
      3. ethtool -K enp4s2 hw-tc-offload on
      4. ip link set ens261f0 vf 0 spoofchk off
      5. tc filter add dev enp4s2 protocol ip parent ffff: prio 1 flower\
      	dst_ip 192.168.3.5/32 ip_proto udp dst_port 25 skip_sw hw_tc 2
      Signed-off-by: NAvinash Dayanand <avinash.dayanand@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      e284fc28
  23. 14 2月, 2018 3 次提交
    • D
      i40e: i40e: Change ethtool check from MAC to HW flag · 7b63435a
      Dave Ertman 提交于
      The MAC, FW Version and NPAR check used to determine
      if shutting off the FW LLDP engine is supported is not
      using the usual feature check mechanism.
      
      This patch fixes the problem by moving the feature check
      to i40e_sw_init in order to set a flag in pf->hw_features
      that ethtool will use for priv_flags disable operation.
      Signed-off-by: NDave Ertman <david.m.ertman@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      7b63435a
    • A
      i40e: do not force filter failure in overflow promiscuous · 7363115e
      Alan Brady 提交于
      Broadcast filters can now cause overflow promiscuous to trigger when
      adding "too many" VLANs to all the ports of a device and the driver
      needs a way to exit overflow promiscuous once triggered.
      
      Currently the driver looks to see if there are "too many" filters and/or
      we have any failed filters to determine when it is safe to exit overflow
      promiscuous.  If we trigger overflow promiscuous with broadcast filters,
      any new filters added will be "auto-failed" until we exit overflow
      promiscuous.  Since the user can't manually remove the failed broadcast
      filters for VLANs (nor should we expect the user to do such), there is
      no way to exit overflow promiscuous without reloading the driver.
      
      The easiest way to do this is to remove the shortcut to "auto-fail"
      filters in overflow promiscuous.  If the user removes the VLANs, the
      failed filters will be removed and since we're no longer "auto-failing"
      new filters, we'll eventually get a good set of filters and exit
      overflow promiscuous.
      
      This has the side benefit of making filter state more explicit in that
      if a filter says it's failed we know for a fact it failed and not just
      assuming it will if we're in overflow promiscuous.  This is nice because
      if the user removes some filters and then adds some, even if we're in
      overflow promiscuous, the filter might succeed; we were just assuming it
      won't because the user hasn't rectified other existing failed filters.
      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>
      7363115e
    • A
      i40e: refactor promisc_changed in i40e_sync_vsi_filters · cc6a96a4
      Alan Brady 提交于
      This code here is quite complex and easy to screw up.  Let's see if we
      can't improve the readability and maintainability a bit.  This refactors
      out promisc_changed into two variables 'old_overflow' and 'new_overflow'
      which makes it a bit clearer when we're concerned about when and how
      overflow promiscuous is changed.  This also makes so that we no longer
      need to pass a boolean pointer to i40e_aqc_add_filters.  Instead we can
      simply check if we changed the overflow promiscuous flag since the
      function start.
      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>
      cc6a96a4