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

On Tue 09 Feb 2021 at 10:42, Or Gerlitz [off-list ref] wrote:

On Sat, Feb 6, 2021 at 7:10 AM Saeed Mahameed [off-list ref] wrote:

quoted

Vlad Buslov says:

quoted

Implement support for VF tunneling

quoted

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.

quoted

SW TC model

maybe before SW TC model, you can explain the vswitch 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, matches on the vport tag and forwards them to
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 based on the MD (LWT
scheme) 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.

Moving tunnel endpoint to VF doesn't change anything in this
high-level description.

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

more or less straight forward based on the above

quoted

From TC perspective VF tunnel configuration requires two rules in both
directions:

quoted

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:

quoted

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:

mmm it's kinda hard managing to follow and catch up a SW model from TC rules..

I think we need these two to begin with (in whatever order that works
better for you)

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

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

quoted

HW offloads model

a clear SW model before HW offloads model..

Hope my replies to Jakub and Marcelo also address these.

quoted

 25 files changed, 3812 insertions(+), 1057 deletions(-)

for adding almost 4K LOCs