netdev - Re: [pull request][net-next V2 00/17] mlx5 updates 2021-02-04

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJ3xEMi9ZTXz8X4k8fvTQF8iPDEn7LbK-pq+7hZdsjbvnuQE-w@mail.gmail.com>
Date:   Mon, 8 Feb 2021 23:55:28 +0200
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Saeed Mahameed <saeed@...nel.org>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Saeed Mahameed <saeedm@...dia.com>
Subject: Re: [pull request][net-next V2 00/17] mlx5 updates 2021-02-04

On Sat, Feb 6, 2021 at 7:10 AM Saeed Mahameed <saeed@...nel.org> wrote:
> From: Saeed Mahameed <saeedm@...dia.com>

> This series adds the support for VF tunneling.

> Vlad Buslov says:
> =================
> Implement support for VF tunneling

> Abstract
> Currently, mlx5 only supports configuration with tunnel endpoint IP address on
> uplink representor. Remove implicit and explicit assumptions of tunnel always
> being terminated on uplink and implement necessary infrastructure for
> configuring tunnels on VF representors and updating rules on such tunnels
> according to routing changes.
>
> SW TC model

maybe before SW TC model, you can explain the SW model (TC is a vehicle
to implement the SW model).

SW model for VST and "classic" v-switch tunnel setup:

For example, in VST model, each virtio/vf/sf vport has a vlan such that
the v-switch tags packets going out "south" of the vport towards the
uplink, untags
packets going "north" from the uplink into the vport (and does nothing
for east-west traffic).

In a similar manner, in "classic" v-switch tunnel setup, each
virtio/vf/sf vport is somehow
associated with VNI/s marking the tenant/s it belongs to. Same tenant
east-west traffic
on the host doesn't go through any encap/decap. The v-switch adds the
relevant tunnel
MD to packets/skbs sent "southward" by the end-point and forwards it
to the VTEP which applies
encap and sends the packets to the wire. On RX, the VTEP decaps the
tunnel info from the packet,
adds it as MD to the skb and forwards the packet up into the stack
where the vsw hooks it, matches
on the MD + inner tuple and then forwards it to the relevant endpoint.

HW offloads for VST and "classic" v-switch tunnel setup:

more or less straight forward based on the above

> From TC perspective VF tunnel configuration requires two rules in both
> directions:
>
> TX rules
>
> 1. Rule that redirects packets from UL to VF rep that has the tunnel
> endpoint IP address:

> 2. Rule that decapsulates the tunneled flow and redirects to destination VF
> representor:

> RX rules
>
> 1. Rule that encapsulates the tunneled flow and redirects packets from
> source VF rep to tunnel device:

> 2. Rule that redirects from tunnel device to UL rep:

Sorry, I am not managing to follow and catch up a SW model from TC rules..

I think we need these two to begin with:

[1] Motivation for enhanced v-switch tunnel setup:

[2] SW model for enhanced v-switch tunnel setup:

> HW offloads model

a clear SW model before HW offloads model..