netdev - Re: [PATCH/RFC net-next] tc: allow drivers to accept gact with PIPE when offloading

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:   Mon, 28 Nov 2022 05:33:19 -0800
From:   Marcelo Leitner <mleitner@...hat.com>
To:     Eelco Chaudron <echaudro@...hat.com>
Cc:     Tianyu Yuan <tianyu.yuan@...igine.com>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Simon Horman <simon.horman@...igine.com>,
        netdev@...r.kernel.org, Cong Wang <xiyou.wangcong@...il.com>,
        Davide Caratti <dcaratti@...hat.com>,
        Edward Cree <edward.cree@....com>,
        Ilya Maximets <i.maximets@....org>,
        Oz Shlomo <ozsh@...dia.com>, Paul Blakey <paulb@...dia.com>,
        Vlad Buslov <vladbu@...dia.com>, dev@...nvswitch.org,
        oss-drivers <oss-drivers@...igine.com>,
        Ziyang Chen <ziyang.chen@...igine.com>
Subject: Re: [PATCH/RFC net-next] tc: allow drivers to accept gact with PIPE
 when offloading

On Mon, Nov 28, 2022 at 02:17:40PM +0100, Eelco Chaudron wrote:
>
>
> On 28 Nov 2022, at 14:11, Marcelo Leitner wrote:
>
> > On Mon, Nov 28, 2022 at 07:11:05AM +0000, Tianyu Yuan wrote:
...
> >>
> >> Furthermore, I think the current stats for each action mentioned in 2) cannot represent the real
> >> hw stats and this is why [ RFC  net-next v2 0/2] (net: flow_offload: add support for per action
> >> hw stats) will come up.
> >
> > Exactly. Then, when this patchset (or similar) come up, it won't
> > update all actions with the same stats anymore. It will require a set
> > of stats from hw for the gact with PIPE action here. But if drivers
> > are ignoring this action, they can't have specific stats for it. Or am
> > I missing something?
> >
> > So it is better for the drivers to reject the whole flow instead of
> > simply ignoring it, and let vswitchd probe if it should or should not
> > use this action.
>
> Please note that OVS does not probe features per interface, but does it per datapath. So if it’s supported in pipe in tc software, we will use it. If the driver rejects it, we will probably end up with the tc software rule only.

Ah right. I remember it will pick 1 interface for testing and use
those results everywhere, which then I don't know if it may or may not
be a representor port or not. Anyhow, then it should use skip_sw, to
try to probe for the offloading part. Otherwise I'm afraid tc sw will
always accept this flow and trick the probing, yes.

  Marcelo