netdev - Re: [net-next,v5,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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181211141735.5ee2e8b7@cakuba.netronome.com>
Date:   Tue, 11 Dec 2018 14:17:35 -0800
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Or Gerlitz <gerlitz.or@...il.com>
Cc:     David Miller <davem@...emloft.net>,
        Florian Westphal <fw@...len.de>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Jiri Pirko <jiri@...lanox.com>, mkubecek@...e.cz,
        Jamal Hadi Salim <jhs@...atatu.com>
Subject: Re: [net-next,v5,00/12] add flow_rule infrastructure

On Tue, 11 Dec 2018 22:59:47 +0200, Or Gerlitz wrote:
> To put it a bit more clearly, donno if my concerns are to the extent of
> being fundamental, but yesknow that they were not sufficiently addressed.
> 
> TC is the leading kernel CA system for about 2.5 decades, so I am not
> clear what we want to IR the TC offload path and not TCfy the ethtool
> and Co offloads path.

I'm not 100% clear on what the proposal would be here.  Would we
build a flow dissector and allocate fake TC actions?  Would we use
setup_tc hook?  My gut worry is that we would just end up with the
worst of all worlds if we do something like this :(  (already to my
taste this API leaks too much TC through)

Back to the elephant in the room it would certainly aid "nft offload"
adoption if drivers didn't even know it was not a real flower being
offloaded :)

> Going forward to 2019 HWs that can offload OVS/OF (flow) metering,
> do we really want to IR the TC policers which follow IEEE or a like specs?

Specs are good (y)

> Still, seems that other folks on the drivers yard are ok and even happy with
> the IR direction/implementation, I see that Jiri acked it all.
> 
> I guess we need some voices to speak, would love to hear the whole
> of the CCed JJJ triplet speaking up.

I don't care much either way.  One thing I really don't look forward to
is trying to do backports and send stable fixes after this conversion.

Maybe having a side library that could take a ethtool/flower/nft flow
and return common IR representation of that flow would be less painful?
Drivers could then migrate at its own pace, for new functionality etc.
Was that discussed before?  I may have lost track of this discussion...