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

Date:   Thu, 2 Jan 2020 09:53:27 +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 Thu, Jan 2, 2020 at 5:04 AM Tonghao Zhang <xiangxia.m.yue@...il.com> wrote:
>
> 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
>

you didn't ask for skip_sw, if you install a rule with "none" and adding to hw
fails, still the rule is fine in the SW data-path

>
> # 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


this (in_hw) seems to be a bug, we don't support it AFAIK

> 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


I think newish (for about a year now or maybe more)  kernels and iproute have
per data-path (SW/HW) rule traffic counters - this would help you
realize what is
going on down there

>
> 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.


indeed, but only if you use skip_sw

still the in_hw indication suggests there a driver bug


>
> > 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.


cool, so production can keep using these rules..


>
> > Hence the claim here is that if PF0.uplink --> hairpin --> PF1.uplink
> > would have been supported


>
> Did we have plan to support that function.


I don't think so, what is the need? something wrong with N+2 rules as
I suggested?