mbox series

[V2,mlx5-next,00/13] Mellanox, mlx5 vport metadata matching

Message ID 20190625174727.20309-1-saeedm@mellanox.com
Headers show
Series Mellanox, mlx5 vport metadata matching | expand

Message

Saeed Mahameed June 25, 2019, 5:47 p.m. UTC 
This series includes mlx5 updates for both rdma and net-next trees.
In case of no objection it will be applied to mlx5-next branch and later
on will be sent as pull request to rdma and net-next.

From Jianbo, Vport meta data matching:

Hardware steering has no notion of vport number, and vport is an
abstract concept, so firmware need to translate the source vport
matching to match on the VHCA ID (Virtual HCA ID).

In dual-port RoCE, the dual-port VHCA is able to send also on the
second port on behalf of the affiliated vport, so now we can’t assume
anymore that vport is represented by single VHCA only.

To resolve this issue, we use metadata register as source port
indicator instead.

When a packet enters the eswitch, eswitch ingress traffic passes the
ingress ACL flow tables, where we tag the packets (via the metadata
value, in this case REG_C at index 0) with a unique value which will
act as an alias of the vport. In order to guarantee uniqueness, we use
the eswitch owner vhca id and the vport number as that value.

Usually, the vports are numbered in each eswitch as followed:
    - Physical Function (PF) vport, the number is 0.
    - Virtual Function (VF) vport, starting from 1.
    - Uplink vport, the reserved vport number for it is 0xFFFF.

With the metadata in each packet, we can then do matching on it, in
both fast path and slow path.

For slow path, there is a representor for each vport. Packet that
misses all offloaded rules in FDB, will be forwarded to the eswitch
manager vport. In its NIC RX, it then will be steered to the right
representor. The rules, which decide the destination representor,
previously were matching on source port, will now match metadata
instead.

V2:
- Remove eswitch cleanup patches from bodong, will submit later.
- Remove IB specified APIs (mlx5_ib_eswitch_*) added in V1.
- Add mlx5_eswitch_is_vf_vport() to check if the vport is VF vport.
- Other small changes.

Thanks,
Saeed.

---

Jianbo Liu (12):
  net/mlx5: Introduce vport metadata matching bits and enum constants
  net/mlx5: Get vport ACL namespace by vport index
  net/mlx5: Support allocating modify header context from ingress ACL
  net/mlx5: Add flow context for flow tag
  net/mlx5: E-Switch, Tag packet with vport number in VF vports and
    uplink ingress ACLs
  net/mlx5e: Specifying known origin of packets matching the flow
  net/mlx5: E-Switch, Add match on vport metadata for rule in fast path
  net/mlx5: E-Switch, Add query and modify esw vport context functions
  net/mlx5: E-Switch, Pass metadata from FDB to eswitch manager
  net/mlx5: E-Switch, Add match on vport metadata for rule in slow path
  RDMA/mlx5: Add vport metadata matching for IB representors
  net/mlx5: E-Switch, Enable vport metadata matching if firmware
    supports it

Parav Pandit (1):
  net/mlx5: Introduce a helper API to check VF vport

 drivers/infiniband/hw/mlx5/flow.c             |  13 +-
 drivers/infiniband/hw/mlx5/main.c             |  75 ++-
 drivers/infiniband/hw/mlx5/mlx5_ib.h          |   1 +
 .../mellanox/mlx5/core/diag/fs_tracepoint.h   |   4 +-
 .../mellanox/mlx5/core/en_fs_ethtool.c        |   2 +-
 .../net/ethernet/mellanox/mlx5/core/en_tc.c   |   7 +-
 .../net/ethernet/mellanox/mlx5/core/eswitch.c |  30 +-
 .../net/ethernet/mellanox/mlx5/core/eswitch.h |  16 +
 .../mellanox/mlx5/core/eswitch_offloads.c     | 500 ++++++++++++++----
 .../ethernet/mellanox/mlx5/core/fpga/ipsec.c  |   8 +-
 .../net/ethernet/mellanox/mlx5/core/fs_cmd.c  |  10 +-
 .../net/ethernet/mellanox/mlx5/core/fs_core.c |  34 +-
 .../net/ethernet/mellanox/mlx5/core/fs_core.h |   1 +
 include/linux/mlx5/eswitch.h                  |  17 +
 include/linux/mlx5/fs.h                       |  16 +-
 include/linux/mlx5/mlx5_ifc.h                 |  56 +-
 16 files changed, 622 insertions(+), 168 deletions(-)

Comments

Saeed Mahameed June 26, 2019, 7:05 p.m. UTC | #1 
On Tue, 2019-06-25 at 17:47 +0000, Saeed Mahameed wrote:
> This series includes mlx5 updates for both rdma and net-next trees.
> In case of no objection it will be applied to mlx5-next branch and
> later
> on will be sent as pull request to rdma and net-next.
> 
> From Jianbo, Vport meta data matching:
> 
> Hardware steering has no notion of vport number, and vport is an
> abstract concept, so firmware need to translate the source vport
> matching to match on the VHCA ID (Virtual HCA ID).
> 
> In dual-port RoCE, the dual-port VHCA is able to send also on the
> second port on behalf of the affiliated vport, so now we can’t assume
> anymore that vport is represented by single VHCA only.
> 
> To resolve this issue, we use metadata register as source port
> indicator instead.
> 
> When a packet enters the eswitch, eswitch ingress traffic passes the
> ingress ACL flow tables, where we tag the packets (via the metadata
> value, in this case REG_C at index 0) with a unique value which will
> act as an alias of the vport. In order to guarantee uniqueness, we
> use
> the eswitch owner vhca id and the vport number as that value.
> 
> Usually, the vports are numbered in each eswitch as followed:
>     - Physical Function (PF) vport, the number is 0.
>     - Virtual Function (VF) vport, starting from 1.
>     - Uplink vport, the reserved vport number for it is 0xFFFF.
> 
> With the metadata in each packet, we can then do matching on it, in
> both fast path and slow path.
> 
> For slow path, there is a representor for each vport. Packet that
> misses all offloaded rules in FDB, will be forwarded to the eswitch
> manager vport. In its NIC RX, it then will be steered to the right
> representor. The rules, which decide the destination representor,
> previously were matching on source port, will now match metadata
> instead.
> 

Series applied to mlx5-next.

Thanks everyone!
Saeed.