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