netdev - Re: mlx5e question about PF fwd packets to PF

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]

Date:   Tue, 31 Dec 2019 22:40:16 +0200
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Tonghao Zhang <xiangxia.m.yue@...il.com>
Cc:     Saeed Mahameed <saeedm@....mellanox.co.il>,
        Roi Dayan <roid@...lanox.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: mlx5e question about PF fwd packets to PF

On Tue, Dec 31, 2019 at 10:39 AM Tonghao Zhang <xiangxia.m.yue@...il.com> wrote:

> In one case, we want forward the packets from one PF to otter PF in eswitchdev mode.

Did you want to say from one uplink to the other uplink? -- this is
not supported.

What we do support is the following (I think you do it by now):

PF0.uplink --> esw --> PF0.VFx --> hairpin --> PF1.VFy --> esw --> PF1.uplink

Hairpin is an offload for SW gateway, SW gateway is an **application** that runs
over two NIC ports -- we allow them to be virtual NIC ports  -- PF0.VFx/PF1.VFy

since e-switch != (SW) gateway --> eswitch offload != (SW) gateway offload

note that steering rules ## (wise)

PF0.uplink --> T1 --> PF0.VFx --> T2 --> PF1.VFy --> T3 --> PF1.uplink

since you use instantiate eswitch on the system, T(ype)1 and T(ype)3 rules
are ones that differentiate packets that belong to this GW. But, T(ype)2 rules,
can be just "fwd everything" -- TC wise, you can even mask out the ethertype,
just a tc/flower rules that fwd everything from ingress PF0.VFx vNIC
to egress  PF1.VFy vNIC.

Further, you can also you this match-all (but with flower..) rule for
the PF1.VFy --> PF1.uplink
part of the chain since you know that everything that originates in
this VF should go to the uplink.

Hence the claim here is that if PF0.uplink --> hairpin --> PF1.uplink
would have been
supported and the system had N steering rules, with what is currently
supported you
need N+2 rules -- N rules + one T2 rule and one T3 rule