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

[Saeed Mahameed <saeedm@mellanox.com>]

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.