netdev - Re: [net-next PATCH v3 00/12] Flow API

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: <20150123140724.GJ25797@casper.infradead.org>
Date:	Fri, 23 Jan 2015 14:07:24 +0000
From:	Thomas Graf <tgraf@...g.ch>
To:	Jiri Pirko <jiri@...nulli.us>
Cc:	Jamal Hadi Salim <jhs@...atatu.com>,
	Pablo Neira Ayuso <pablo@...filter.org>,
	John Fastabend <john.fastabend@...il.com>,
	simon.horman@...ronome.com, sfeldma@...il.com,
	netdev@...r.kernel.org, davem@...emloft.net, gerlitz.or@...il.com,
	andy@...yhouse.net, ast@...mgrid.com
Subject: Re: [net-next PATCH v3 00/12] Flow API

On 01/23/15 at 02:43pm, Jiri Pirko wrote:
> Fri, Jan 23, 2015 at 01:28:38PM CET, tgraf@...g.ch wrote:
> >If I understand this correctly then you propose to do the decision on
> >whether to implement a flow in software or offload it to hardware in the
> >xflows classifier and action. I had exactly the same architecture in mind
> >initially when I first approached this and wanted to offload OVS
> >datapath flows transparently to hardware.
> 
> Think about xflows as an iface to multiple backends, some sw and some hw.
> User will be able to specify which backed he wants to use for particular
> "commands".
> 
> So for example, ovs kernel datapath module will implement an xflows
> backend and register it as "ovsdp". Rocker will implement another xflows
> backend and register it as "rockerdp". Then, ovs userspace will use xflows
> api to setup both backends independently, but using the same xflows api.
> 
> It is still up to userspace to decide what should be put where (what
> backend to use).

OK, sounds good so far. Although we can't completely ditch the existing
genl based OVS flow API for obvious backwards compatibility reasons ;-)

How does John's API fit into this? How would you expose capabilities
through xflows? How would it differ from what John proposes?

Since this would be a regular tc classifier I assume it could be
attached to any tc class and interface and then combined with other
classifiers which OVS would not be aware of. How do you intend to
resolve such conflicts?

Example:
 eth0:
   ingress qdisc:
     cls prio 20 u32 match [...]
     cls prio 10 xflows [...]

If xflows offloads to hardware, the u32 classifier with higher
priority is hidden unintentionally.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html