1. 20 3月, 2018 1 次提交
  2. 15 3月, 2018 4 次提交
  3. 27 2月, 2018 1 次提交
  4. 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
  5. 14 2月, 2018 6 次提交
  6. 13 2月, 2018 4 次提交
  7. 08 2月, 2018 1 次提交
  8. 27 1月, 2018 6 次提交
  9. 26 1月, 2018 1 次提交
  10. 25 1月, 2018 1 次提交
  11. 24 1月, 2018 7 次提交
  12. 11 1月, 2018 1 次提交
  13. 04 1月, 2018 3 次提交
    • J
      i40e: flower: Fix return value for unsupported offload · bc4244c6
      Jiri Pirko 提交于
      When filter configuration is not supported, drivers should return
      -EOPNOTSUPP so the core can react correctly.
      
      Fixes: 2f4b411a ("i40e: Enable cloud filters via tc-flower")
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      bc4244c6
    • J
      i40e: don't remove netdev->dev_addr when syncing uc list · 458867b2
      Jacob Keller 提交于
      In some circumstances, such as with bridging, it is possible that the
      stack will add a devices own MAC address to its unicast address list.
      
      If, later, the stack deletes this address, then the i40e driver will
      receive a request to remove this address.
      
      The driver stores its current MAC address as part of the MAC/VLAN hash
      array, since it is convenient and matches exactly how the hardware
      expects to be told which traffic to receive.
      
      This causes a problem, since for more devices, the MAC address is stored
      separately, and requests to delete a unicast address should not have the
      ability to remove the filter for the MAC address.
      
      Fix this by forcing a check on every address sync to ensure we do not
      remove the device address.
      
      There is a very narrow possibility of a race between .set_mac and
      .set_rx_mode, if we don't change netdev->dev_addr before updating our
      internal MAC list in .set_mac. This might be possible if .set_rx_mode is
      going to remove MAC "XYZ" from the list, at the same time as .set_mac
      changes our dev_addr to MAC "XYZ", we might possibly queue a delete,
      then an add in .set_mac, then queue a delete in .set_rx_mode's
      dev_uc_sync and then update netdev->dev_addr. We can avoid this by
      moving the copy into dev_addr prior to the changes to the MAC filter
      list.
      
      A similar race on the other side does not cause problems, as if we're
      changing our MAC form A to B, and we race with .set_rx_mode, it could
      queue a delete from A, we'd update our address, and allow the delete.
      This seems like a race, but in reality we're about to queue a delete of
      A anyways, so it would not cause any issues.
      
      A race in the initialization code is unlikely because the netdevice has
      not yet been fully initialized and the stack should not be adding or
      removing addresses yet.
      
      Note that we don't (yet) need similar code for the VF driver because it
      does not make use of __dev_uc_sync and __dev_mc_sync, but instead roles
      its own method for handling updates to the MAC/VLAN list, which already
      has code to protect against removal of the hardware address.
      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>
      458867b2
    • A
      i40e: Remove UDP support for big buffer · 64e711ca
      Amritha Nambiar 提交于
      Since UDP based filters are not supported via big buffer cloud
      filters, remove UDP support.  Also change a few return types to
      indicate unsupported vs invalid configuration.
      Signed-off-by: NAmritha Nambiar <amritha.nambiar@intel.com>
      Acked-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>
      64e711ca
  14. 28 11月, 2017 1 次提交
  15. 22 11月, 2017 2 次提交