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.
