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]

Message-ID: <CAMDZJNXWG6jkNwub_nenx9FpKJB8PK7VTFj9wiUn+xM7-CfK3w@mail.gmail.com>
Date:   Thu, 2 Jan 2020 11:03:47 +0800
From:   Tonghao Zhang <xiangxia.m.yue@...il.com>
To:     Or Gerlitz <gerlitz.or@...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 Wed, Jan 1, 2020 at 4:40 AM Or Gerlitz <gerlitz.or@...il.com> wrote:
>
> 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.
yes, I try to install one rule and hope that one uplink can forward
the packets to other uplink of PF.
But the rule can be installed successfully, and the counter of rule is
changed as show below:

# tc filter add dev $PF0 protocol all parent ffff: prio 1 handle 1
flower action mirred egress redirect dev $PF1

# tc -d -s filter show dev $PF0 ingress
filter protocol all pref 1 flower chain 0
filter protocol all pref 1 flower chain 0 handle 0x1
  in_hw
action order 1: mirred (Egress Redirect to device enp130s0f1) stolen
  index 1 ref 1 bind 1 installed 19 sec used 0 sec
  Action statistics:
Sent 3206840 bytes 32723 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0

The PF1 uplink don't sent the packets out(as you say, we don't support it now).
If we don't support it, should we return -NOSUPPORT when we install
the hairpin rule between
uplink of PF, because it makes me confuse.
> 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
Yes, I have tested it, and it work fine for us.
> 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
Did we have plan to support that function.
> 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 rul