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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 26 Jun 2019 19:05:46 +0000
From:   Saeed Mahameed <saeedm@...lanox.com>
To:     Leon Romanovsky <leonro@...lanox.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>
Subject: Re: [PATCH V2 mlx5-next 00/13] Mellanox, mlx5 vport metadata matching

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.