netdev - Re: [PATCH net-next,v4 00/12] 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: <20181129165315.GA2234@nanopsycho.orion>
Date:   Thu, 29 Nov 2018 17:53:15 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     John Fastabend <john.fastabend@...il.com>
Cc:     Pablo Neira Ayuso <pablo@...filter.org>, netdev@...r.kernel.org,
        davem@...emloft.net, thomas.lendacky@....com, f.fainelli@...il.com,
        ariel.elior@...ium.com, michael.chan@...adcom.com,
        santosh@...lsio.com, madalin.bucur@....com,
        yisen.zhuang@...wei.com, salil.mehta@...wei.com,
        jeffrey.t.kirsher@...el.com, tariqt@...lanox.com,
        saeedm@...lanox.com, jiri@...lanox.com, idosch@...lanox.com,
        jakub.kicinski@...ronome.com, peppe.cavallaro@...com,
        grygorii.strashko@...com, andrew@...n.ch,
        vivien.didelot@...oirfairelinux.com, alexandre.torgue@...com,
        joabreu@...opsys.com, linux-net-drivers@...arflare.com,
        ganeshgr@...lsio.com, ogerlitz@...lanox.com,
        Manish.Chopra@...ium.com, marcelo.leitner@...il.com
Subject: Re: [PATCH net-next,v4 00/12] add flow_rule infrastructure

Thu, Nov 29, 2018 at 04:47:07PM CET, john.fastabend@...il.com wrote:
>On 11/28/18 6:22 PM, Pablo Neira Ayuso wrote:
>> Hi,
>> 
>> This patchset is another iteration to introduce an in-kernel intermediate
>> representation (IR) to express ACL hardware offloads [1] [2] [3].
>> 
>
>Hi,
>
>Also wanted to add. In an earlier thread it was mentioned this could be
>used for other offload rule infrastructures specifically u32 was
>mentioned. I don't think this is actually possible on the flow_rule
>side. This set uses basically an enum based key system where enums
>such as FLOW_DISSECTOR_KEY_* identify the field in the packet. For
>every field we want to match a new key is needed. But the u32 classifier
>defines fields using offset/mask and a parse graph. They do not seem
>compatible to me so in the end this unifies ethtool and flower only.
>Did I get this right?
>
>So would it be better to simply map ethtool onto flower vs defining
>a new one? Patch 1 seems to be pretty light-weight so maybe rather
>than calling it a new IR we just need some helper routines for
>drivers to work with.

You don't really want to create TC internal structures in order to
offload ethtool stuff. So you need something generic and subsystem
agnostic so you can use it by both (and possibly more). And that is
exactly what this patchset is doing.

U32 is on the side. You still offload u32 via existing structs. No
change there. Nobody is pushing u32 to use any other structs.
If later on (I don't see it likely) there will be another subsystem
using u32-like structures, we can find the generic structs for that too.


>
>Probably a more detailed cover letter explaining motivation
>and any future work would help (me at least) understand the direction.
>I see netfilter offload was mentioned at one point so maybe that is
>the motivation that makes it more clear why flower API today is
>insufficient. Mostly curious at this point I see Jiri and Florian
>both reviewed it already.
>
>Thanks,
>John