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
| ||
|
Message-Id: <1287404217.3664.182.camel@bigi> Date: Mon, 18 Oct 2010 08:16:57 -0400 From: jamal <hadi@...erus.ca> To: Jesse Gross <jesse@...ira.com> Cc: Ben Pfaff <blp@...ira.com>, netdev@...r.kernel.org, ovs-team@...ira.com Subject: Re: openvswitch/flow WAS ( Re: [rfc] Merging the Open vSwitch datapath On Sat, 2010-10-16 at 12:33 -0700, Jesse Gross wrote: > On Sat, Oct 16, 2010 at 4:35 AM, jamal <hadi@...erus.ca> wrote: > Yes, Open vSwitch supports the OpenFlow protocol. However, the Open > vSwitch kernel portion is completely different from the OpenFlow > reference implementation datapath and in fact does not speak OpenFlow > at the kernel level. Excellent. Sorry - I may have misread the openflow code to be openvswitch. > You brought up the point of keeping the kernel > simple and making policy decisions in userspace. I completely agree > and, in fact, that is the reason why Open vSwitch is designed the way > it is. > > I think it might be helpful if I gave a high level overview of packet > processing: > > When a packet is received it, the relevant fields from the packet are > extracted and matched against a hash table. The most interesting part > is actually what happens when the packets don't match a hash entry: > they get sent up to userspace. It is userspace that makes a policy > decision about the traffic and then pushes down a flow entry for > future packets to match. Some of the things that those decisions can > be based on include: OpenFlow rules, wildcarded entries, normal L2 > learning, etc. From then on, packets in that flow can be processed on > the fast path in the kernel with minimal overhead, while still getting > the benefit of the knowledge of userspace. Ok, pretty classical stuff - exception handling in control path, update policy to data path based on exception, subsequent stuff happens in data path. > So I think that we are actually in agreement on quite a number of > points: the kernel should be kept as simple as possible, the control > plane should be abstracted out and handled in userspace, and it should > be possible to map the control rules (from OpenFlow or anywhere > really) onto a simpler set of primitives for handling packets. > > So with those goals in mind, here's what is needed: > 1. Packet field extraction and classification. Realistically speaking > a new, specialized classifier would probably be needed, as you > mention. I think a new classifier would make life simpler here. > 2. A mechanism to send/receive packets to/from userspace. This is an > important component that Open vSwitch adds to the pipeline. This will > probably expand in the future to suit different applications, like the > security processing that I talked about. There are many ways to skin that proverbial cat. I guess it will depend on whether you are redirecting or merely copying a whole packet, or part of it (while storing a part in the kernel) etc. Example for a scheme that works using netlink look at the netfilter examples. You could use pf_packet if merely requiring copies. One simple scheme i have used is to have the mirred action redirect to a tun device on which a user space daemon is listening. If you look at the mirred action - there is an option to redirect to a named socket which was never implemented because workarounds exist. > 3. Output actions. A few exist today, at least some new ones will > need to be added. Agreed. > So in reality, all of major components of Open vSwitch are actually > not present in the kernel today. I know the argument could be made > that certains parts can be replicated in different ways but that's > back to the simplicity point that I was making earlier. The u32 > classifier isn't well suited for these types of rules and neither is > pedit. If we're going to add the needed components either way, let's > not make everyone's lives more complicated by mixing everything > together. I have to say it is a pleasant suprise that we agree. When i looked at the openflow code i was worried. I always believe in improving what we have in Linux than trying to add parallel competing interfaces. [You'd be suprised for example on the number of vendors who put forward the claim that they can route faster on Linux[1] by writing a little barebone driver which ignores 99% of reality.] cheers, jamal [1] I am forgiving on academics -- 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
Powered by blists - more mailing lists