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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAJ3xEMg+v2DSHn=J9tz2P8AMVS3bWxwTZnWOgc4S=V+tK=DKOw@mail.gmail.com>
Date:   Thu, 13 Dec 2018 12:06:39 +0200
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.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 Wed, Dec 12, 2018 at 12:17 AM Jakub Kicinski
<jakub.kicinski@...ronome.com> wrote:
>
> 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)

yeah it was something in this direction, but I hear that you don't like it and
I guess Jiri is also not advocating for that, so maybe that not a right choice.

> 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 :)

after this Dave put the EIR on the thread someone put on table a photo
of office scene with nice Elephant looking on the happenings, so I have it
every morning now..

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

I understand you are saying we can IR the TC policers, let it be.

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

M2

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

Currently all drivers are ported to use the IR on the tc/flower offload path

End of the day, seems that Jiri and Jakub are good with this and I didn't hear
any further rejections from other driver folks, so I guess my concerns
were basically
addressed by them.