1. 01 Nov, 2021 27 commits
  2. 30 Oct, 2021 5 commits
  3. 29 Oct, 2021 8 commits
    • Ariel Levkovich's avatar
      net/mlx5: Support internal port as decap route device · b16eb3c8
      Ariel Levkovich authored
      When performing route device lookup for decap action, support
      the case of ovs internal port as the lookup result.
      
      In such case, an internal port struct is mapped and attached
      to the flow attributes so that the source port matching of the
      rule will match on the internal port's metadata value.
      Signed-off-by: default avatarAriel Levkovich <lariel@nvidia.com>
      Reviewed-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      b16eb3c8
    • Ariel Levkovich's avatar
      net/mlx5e: Term table handling of internal port rules · 5e994272
      Ariel Levkovich authored
      Adjust termination table logic to handle rules which
      involve internal port as filter or forwarding device.
      
      For cases where the rule forwards from internal port
      to uplink, always choose to go via termination table.
      This is because it is not known from where the packet
      originally arrived to the internal port and it is possible
      that it came from the uplink itself, in which case
      a term table is required to perform hairpin.
      If the packet arrived from a vport, going via term
      table has no effect.
      
      For cases where the rule forwards to an internal port
      from uplink the rep pointer will point to the uplink rep,
      avoid going via termination table as it is not required.
      Signed-off-by: default avatarAriel Levkovich <lariel@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      5e994272
    • Ariel Levkovich's avatar
      net/mlx5e: Add indirect tc offload of ovs internal port · 166f431e
      Ariel Levkovich authored
      Register callbacks for tc blocks of ovs internal port devices.
      
      This allows an indirect offloading rules that apply on
      such devices as the filter device.
      
      In case a rule is added to a tc block of an internal port,
      the mlx5 driver will implicitly add a matching on the internal
      port's unique vport metadata value to the rule's matching list.
      Therefore, only packets that previously hit a rule that redirects
      to an internal port and got the vport metadata overwritten to the
      internal port's unique metadata, can match on such indirect rule.
      
      Offloading of both ingress and egress tc blocks of internal ports
      is supported as opposed to other devices where only ingress block
      offloading is supported.
      Signed-off-by: default avatarAriel Levkovich <lariel@nvidia.com>
      Reviewed-by: default avatarPaul Blakey <paulb@nvidia.com>
      Reviewed-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      166f431e
    • Ariel Levkovich's avatar
      net/mlx5e: Offload internal port as encap route device · 100ad4e2
      Ariel Levkovich authored
      When pefroming encap action, a route lookup is performed
      to find the routing device the packet should be forwarded
      to after the encapsulation. This is the device that has the
      local tunnel ip address.
      
      This change adds support to offload an encap rule where the
      route device ends up being an ovs internal port.
      In such case, the driver will add a HW rule that will encapsulate
      the packet with the tunnel header and will overwrite the vport
      metadata in reg_c0 to the internal port metadata value.
      Finally, the packet will be forwarded to the root table to be
      processed again with the indication that it came from an internal
      port.
      Signed-off-by: default avatarAriel Levkovich <lariel@nvidia.com>
      Reviewed-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      100ad4e2
    • Ariel Levkovich's avatar
      net/mlx5e: Offload tc rules that redirect to ovs internal port · 27484f71
      Ariel Levkovich authored
      Allow offloading rules that redirect to ovs internal port
      ingress and egress.
      
      To support redirect to ingress device, offloading of REDIRECT_INGRESS
      action is added.
      
      When a tc rule redirects to ovs internal port, the hw rule will
      overwrite the input vport value in reg_c0 with a new vport metadata
      value that is mapped for this internal port using the internal
      port mapping api that is introduce in previous patches.
      After that the hw rule will redirect the packet to the root table
      to continue processing with the new vport metadata value.
      
      The new vport metadata value indicates that this packet is now
      arriving through an internal port and therefore should be processed
      using rules that apply on the same internal port as the filter device.
      Therefore, following rules that apply on this internal port will have
      to match on the same vport metadata value as part of their matching
      keys to make sure the packet belongs to the internal port.
      Signed-off-by: default avatarAriel Levkovich <lariel@nvidia.com>
      Reviewed-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      27484f71
    • Ariel Levkovich's avatar
      net/mlx5e: Accept action skbedit in the tc actions list · dbac71f2
      Ariel Levkovich authored
      Setting the skb packet type field to host is usually
      done when performing forwarding to ingress device.
      
      This is required since the receive handling that is used
      by the redirect to ingress action checks whether the packet
      doesn't belong to this host and drops the packet in such case.
      
      In order to be able to offload action redirect ingress, tc offload
      code needs to accept the skbedit ptype action as well.
      
      There's no special handling in HW for such action since it will
      be followed by a redirect action and therefore, this code
      only allows us to accept such action in the actions list but
      not performing anything specific in HW for it.
      Signed-off-by: default avatarAriel Levkovich <lariel@nvidia.com>
      Reviewed-by: default avatarPaul Blakey <paulb@nvidia.com>
      Reviewed-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      dbac71f2
    • Ariel Levkovich's avatar
      net/mlx5: E-Switch, Add ovs internal port mapping to metadata support · 4f4edcc2
      Ariel Levkovich authored
      Adding infrastructure to map ovs internal port device to vport
      match metadata to support offload of rules with internal port as
      the filter device or as the destination device.
      
      The infrastructure allows adding and removing internal port device
      to an eswitch database and getting a unique vport metadata value to
      be placed and match on in reg_c0 when offloading rules that are coming
      from or going to an internal port.
      
      The new int port metadata can be written to the source port register
      in HW to indicate that current source port of the packet is the
      internal port and not one of the actual HW vports (uplink or VF).
      Using this method, it is possible to offload TC rules with an OVS
      internal port as their destination port (overwriting the src vport
      register) or as the filter port (matching on the value of the src
      vport register and making sure it matches to the internal port's
      value).
      
      There is also a need to handle a miss case where the packet's
      src port value was changed in HW to an internal port but a following
      rule which matches on this new src port value wasn't found in HW.
      
      In such case, the packet will be forwarded to the driver with
      metadata which allows driver to restore the info of the internal
      port's netdevice. Once this info is restored, the uplink driver
      can forward the packet to the relevant netdevice in SW.
      Signed-off-by: default avatarAriel Levkovich <lariel@nvidia.com>
      Reviewed-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      4f4edcc2
    • Ariel Levkovich's avatar
      net/mlx5e: Use generic name for the forwarding dev pointer · 189ce08e
      Ariel Levkovich authored
      Rename tun_dev to fwd_dev within mlx5e_tc_update_priv struct
      since future implementation may introduce other device types
      which the handler is forwarding to.
      Signed-off-by: default avatarAriel Levkovich <lariel@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      189ce08e