netdev - Re: [PATCH 00/10] add flow

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: <CAJ3xEMggYhmdk0eRQnOgoxBx80y_GprH-AOjXCC5WkeGP+hU1A@mail.gmail.com>
Date:   Fri, 16 Nov 2018 12:29:29 +0200
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Pablo Neira Ayuso <pablo@...filter.org>
Cc:     Linux Netdev List <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>, thomas.lendacky@....com,
        Florian Fainelli <f.fainelli@...il.com>,
        Ariel Elior <ariel.elior@...ium.com>,
        Michael Chan <michael.chan@...adcom.com>, santosh@...lsio.com,
        madalin.bucur@....com,
        "Zhuangyuzeng (Yisen)" <yisen.zhuang@...wei.com>,
        Salil Mehta <salil.mehta@...wei.com>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        Tariq Toukan <tariqt@...lanox.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Ido Schimmel <idosch@...lanox.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        peppe.cavallaro@...com, grygorii.strashko@...com,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        alexandre.torgue@...com, joabreu@...opsys.com,
        linux-net-drivers@...arflare.com,
        Ganesh Goudar <ganeshgr@...lsio.com>
Subject: Re: [PATCH 00/10] add flow_rule infrastructure

On Fri, Nov 16, 2018 at 3:43 AM Pablo Neira Ayuso <pablo@...filter.org> wrote:
> This patchset introduces a kernel intermediate representation (IR) to
> express ACL hardware offloads, this is heavily based on the existing
> flow dissector infrastructure and the TC actions. This IR can be used by
> different frontend ACL interfaces such as ethtool_rxnfc and tc to

any reason to keep aRFS out?

> represent ACL hardware offloads. Main goal is to simplify the
> development of ACL hardware offloads for the existing frontend
> interfaces, the idea is that driver developers do not need to add one
> specific parser for each ACL frontend, instead each frontend can just
> generate this flow_rule IR and pass it to drivers to populate the
> hardware IR.

yeah, but we are adding one more chain (IR), today we have

kernel frontend U/API X --> kernel parser Y --> driver --> HW API
kernel frontend U/API Z --> kernel parser W --> driver --> HW API

and we move to

kernel frontend U/API X --> kernel parser Y --> IR --> driver --> HW API
kernel frontend U/API Z --> kernel parser W --> IR --> driver --> HW API

So instead of

Y --> HW
W --> HW

we have IR --> HW while loosing the TC semantics and spirit in the drivers.

We could have normalize all the U/APIs to use the flow dissectors and
the TC actions and then have the drivers to deal with TC only.

IMHO flow dissectors and TC actions are the right approach to deal with ACLs
HW offloading. They properly reflect how ACLs work in modern HW pipelines.

>
>                 .   ethtool_rxnfc   tc
>                |       (ioctl)    (netlink)
>                |          |         |     translate native
>       Frontend |          |         |  interface representation
>                |          |         |      to flow_rule IR
>                |          |         |
>                 .         \/        \/
>                 .         flow_rule IR
>                |                |
>        Drivers |                | parsing of flow_rule IR
>                |                |  to populate hardware IR
>                |               \/
>                 .      hardware IR (driver)
>
> For design and implementation details, please have a look at:
>
>         https://lwn.net/Articles/766695/

I will further look next week, but as this is not marked as RFC (and
not with net-next
on the title), can we consider this still a discussion and not final/review?

> As an example, with this patchset, it should be possible to simplify the
> existing net/qede driver which already has two parsers to populate the
> hardware IR, one for ethtool_rxnfc interface and another for tc.

I think it would be fair to ask for one such driver porting to see the
impact/benefit.

Or.