From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Subject: Re: [net-next,v5,00/12] add flow_rule infrastructure
Date: Thu, 13 Dec 2018 11:23:15 -0800
Message-ID: <20181213112315.7ea76799@cakuba.netronome.com>
References: <20181206224002.5109-1-pablo@netfilter.org>
        <20181211153519.GA920@strlen.de>
        <20181211.111420.9962444018507543.davem@davemloft.net>
        <CAJ3xEMi1SXxUBCc_pskVOkM94Y9BR8Ky8tzNL0c3tCE1AChomw@mail.gmail.com>
        <20181211141735.5ee2e8b7@cakuba.netronome.com>
        <CAJ3xEMg+v2DSHn=J9tz2P8AMVS3bWxwTZnWOgc4S=V+tK=DKOw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: David Miller <davem@davemloft.net>,
        Florian Westphal <fw@strlen.de>,
        Pablo Neira Ayuso <pablo@netfilter.org>,
        Linux Netdev List <netdev@vger.kernel.org>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Jiri Pirko <jiri@mellanox.com>, mkubecek@suse.cz,
        Jamal Hadi Salim <jhs@mojatatu.com>
To: Or Gerlitz <gerlitz.or@gmail.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-qt1-f171.google.com ([209.85.160.171]:45345 "EHLO
        mail-qt1-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1727608AbeLMTXV (ORCPT
        <rfc822;netdev@vger.kernel.org>); Thu, 13 Dec 2018 14:23:21 -0500
Received: by mail-qt1-f171.google.com with SMTP id e5so3445909qtr.12
        for <netdev@vger.kernel.org>; Thu, 13 Dec 2018 11:23:20 -0800 (PST)
In-Reply-To: <CAJ3xEMg+v2DSHn=J9tz2P8AMVS3bWxwTZnWOgc4S=V+tK=DKOw@mail.gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Thu, 13 Dec 2018 12:06:39 +0200, Or Gerlitz wrote:
> > 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.

I think having the drivers call the IR translation could be a good
compromise instead of having flower always pass down converted flows.

tc flower ->  flower offload object -> setup_tc   -> driver -> 
  -> flow_offload_from_flower() -> driver -> driver's common handling

This patchset already does that for ethtool:

ethtool   ->  ethtool flow          -> ethtool_op -> driver -> 
  -> ethtool_rx_flow_rule_create() -> driver -> driver's common handling

It feels like a bit of a waste to let the driver patches go, but
perhaps it's a good way to move forward?