From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Subject: Re: [net-next,v5,00/12] add flow_rule infrastructure Date: Tue, 11 Dec 2018 14:17:35 -0800 Message-ID: <20181211141735.5ee2e8b7@cakuba.netronome.com> References: <20181206224002.5109-1-pablo@netfilter.org> <20181211153519.GA920@strlen.de> <20181211.111420.9962444018507543.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: David Miller , Florian Westphal , Pablo Neira Ayuso , Linux Netdev List , Florian Fainelli , Jiri Pirko , mkubecek@suse.cz, Jamal Hadi Salim To: Or Gerlitz Return-path: Received: from mail-qt1-f180.google.com ([209.85.160.180]:41684 "EHLO mail-qt1-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726209AbeLKWRm (ORCPT ); Tue, 11 Dec 2018 17:17:42 -0500 Received: by mail-qt1-f180.google.com with SMTP id d18so18339532qto.8 for ; Tue, 11 Dec 2018 14:17:42 -0800 (PST) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: 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...