Re: [net-next,v5,00/12] add flow_rule infrastructure

From: Or Gerlitz <gerlitz.or@gmail.com>
To: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: David Miller <davem@davemloft.net>,
	Florian Westphal <fw@strlen.de>,
	Pablo Neira Ayuso <pablo@netfilter.org>,
	Linux Netdev List <netdev@vger.kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Jiri Pirko <jiri@mellanox.com>,
	mkubecek@suse.cz, Jamal Hadi Salim <jhs@mojatatu.com>
Subject: Re: [net-next,v5,00/12] add flow_rule infrastructure
Date: Thu, 13 Dec 2018 12:06:39 +0200	[thread overview]
Message-ID: <CAJ3xEMg+v2DSHn=J9tz2P8AMVS3bWxwTZnWOgc4S=V+tK=DKOw@mail.gmail.com> (raw)
In-Reply-To: <20181211141735.5ee2e8b7@cakuba.netronome.com>

On Wed, Dec 12, 2018 at 12:17 AM Jakub Kicinski
<jakub.kicinski@netronome.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.