Thread (32 messages) 32 messages, 7 authors, 2018-12-13

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

From: Or Gerlitz <hidden>
Date: 2018-12-13 10:06:52

On Wed, Dec 12, 2018 at 12:17 AM Jakub Kicinski
[off-list ref] wrote:
On Tue, 11 Dec 2018 22:59:47 +0200, Or Gerlitz wrote:
quoted
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..
quoted
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.
quoted
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.
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help