From: Thomas Graf <tgraf@suug.ch>
To: Jiri Pirko <jiri@resnulli.us>
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, jhs@mojatatu.com, jesse@nicira.com
Subject: Re: [patch net-next v3] tc: introduce OpenFlow classifier
Date: Fri, 10 Apr 2015 11:03:17 +0100 [thread overview]
Message-ID: <20150410100317.GD23070@casper.infradead.org> (raw)
In-Reply-To: <20150410091203.GA2021@nanopsycho.orion>
On 04/10/15 at 11:12am, Jiri Pirko wrote:
> Thu, Apr 09, 2015 at 11:34:23PM CEST, davem@davemloft.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.
next prev parent reply other threads:[~2015-04-10 10:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-09 12:58 [patch net-next v3] tc: introduce OpenFlow classifier Jiri Pirko
2015-04-09 13:00 ` [patch iproute2 v3] tc: add support for " Jiri Pirko
2015-04-09 21:34 ` [patch net-next v3] tc: introduce " David Miller
2015-04-10 9:12 ` Jiri Pirko
2015-04-10 9:30 ` Daniel Borkmann
2015-04-10 11:46 ` Jiri Pirko
2015-04-10 13:48 ` Jamal Hadi Salim
2015-04-10 10:03 ` Thomas Graf [this message]
2015-04-10 12:23 ` David Miller
2015-04-10 12:45 ` Jiri Pirko
2015-04-11 16:12 ` Alexei Starovoitov
2015-04-12 7:53 ` Jiri Pirko
2015-04-12 23:44 ` David Miller
2015-04-13 0:12 ` Alexei Starovoitov
2015-04-13 0:36 ` David Miller
2015-04-13 1:03 ` Alexei Starovoitov
2015-04-13 8:26 ` Thomas Graf
2015-04-13 14:34 ` Jiri Pirko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150410100317.GD23070@casper.infradead.org \
--to=tgraf@suug.ch \
--cc=davem@davemloft.net \
--cc=jesse@nicira.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).