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

Or Gerlitz
2018-12-13T10:06:52Z

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.