netdev - Re: [patch net-next v3] tc: introduce OpenFlow classifier

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: <20150410100317.GD23070@casper.infradead.org>
Date:	Fri, 10 Apr 2015 11:03:17 +0100
From:	Thomas Graf <tgraf@...g.ch>
To:	Jiri Pirko <jiri@...nulli.us>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	jhs@...atatu.com, jesse@...ira.com
Subject: Re: [patch net-next v3] tc: introduce OpenFlow classifier

On 04/10/15 at 11:12am, Jiri Pirko wrote:
> Thu, Apr 09, 2015 at 11:34:23PM CEST, davem@...emloft.net wrote:
> >I'm not so sure what my opinion is about whether we should
> >even have an openflow classifier or not (I find major aspects
> >of OpenFLOW extremely distasteful, it's basically pushing the
> >SDK agenda of several major chip vendors).
> 
> Yep, I don't like OpenFlow as well. But anyway, we already have
> OpenFlow-based classifier in kernel - in OVS code.

Can we stop referring to OpenFlow? There is really no relation ;-)
In fact, there are several open source projects which utilize the
OVS kernel datapath *without* caring about OpenFlow at all. A good
example of this is Midonet.

> The thing is, why don't have it in tc? It does not cost anything. And
> having it, people used to use ovs kernel DP will be able to migrate
> easily to tc.

That part I agree with. We should have a single common flow dissector
which is used for all purposes. After all, it's just parsing and
wildcard matching through hash tables. If that flow dissector is not
rich enough for someone, eBPF offers a more programmable approach and
we already see that work progressing nicely. We should also
consolidate as much of the actions as possible.

As I stated in a private email to a couple of days ago. I've started
working on ripping out most of the OVS vport logic and make all OVS
bridge ports be regular net_devices (most of them already were). This
will get rid of most of the OVS specific tunnel handling logic and
should allow to implement flow based tunnels with iproute2 as well.
The OVS datapath structure will just become net_device private data
and all ports will be regular slaves.

Adding slaves to an OVS bridge will be possible through iproute2
and we can even expose OVS bridges as regular Linux bridges ithrough
AF_BRIDGE *if* we want. Although I'm not sure how feasiable that is
given that most Linux bridge knobs including all the STP config
does not apply to OVS bridges.

I think everybody agrees that we should melt as much as possible and
stop reimplementing everything from scratch in isolated silos for
every bridge flavour that pops up.
--
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