netdev - Re: [net-next,v5,00/12] add flow

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181213112315.7ea76799@cakuba.netronome.com>
Date:   Thu, 13 Dec 2018 11:23:15 -0800
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Or Gerlitz <gerlitz.or@...il.com>
Cc:     David Miller <davem@...emloft.net>,
        Florian Westphal <fw@...len.de>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Jiri Pirko <jiri@...lanox.com>, mkubecek@...e.cz,
        Jamal Hadi Salim <jhs@...atatu.com>
Subject: Re: [net-next,v5,00/12] add flow_rule infrastructure

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?