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: <AANLkTin-zmQdMC_nRvgRr5KdWQvee5xga5sjOfRN2McN@mail.gmail.com> Date: Sat, 16 Oct 2010 12:33:25 -0700 From: Jesse Gross <jesse@...ira.com> To: hadi@...erus.ca 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, Oct 16, 2010 at 4:35 AM, jamal <hadi@...erus.ca> wrote: > On Fri, 2010-10-15 at 14:35 -0700, Jesse Gross wrote: > >> >> You're right, at a high level, it appears that there is a bit of an >> overlap between bridging, tc, and Open vSwitch. > > It looks like openvswitch rides on top of openflow, correct? > earlier i was looking at openflow/datapath but gleaning > openvswitch/datapath it still looks conceptually the same > at the lower level. 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. 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. 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. 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. 3. Output actions. A few exist today, at least some new ones will need to be added. 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. -- 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