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