On Thu, 24 Nov 2011 17:30:33 -0500 jamal <h...@cyberus.ca> wrote: > Jesse, > > I am going to try and respond to your comments below. > > On Thu, 2011-11-24 at 12:10 -0800, Jesse Gross wrote: > > > > > * Switching infrastructure: As the name implies, Open vSwitch is > > intended to be a network switch, focused on > > virtualization/OpenFlow/software defined networking. This means that > > what we are modeling is not actually a collection of flows but a > > switch which contains a group of related ports, a software virtual > > device, etc. The switch model is used in a variety of places, such as > > to measure traffic that actually flows through it in order to > > implement monitoring and sampling protocols. > > Can you explain why you couldnt use the current bridge code (likely with > some mods)? I can see you want to isolate the VMs via the virtual ports; > maybe even vlans on the virtual ports - the current bridge code should > be able to handle that.
The way openvswitch works is that the flow table is populated by user space. The kernel bridge works completely differently (it learns about MAC addresses). > > * Flow lookup: Although used to implement OpenFlow, the kernel flow > > table does not actually directly contain OpenFlow flows. This is > > because OpenFlow tables can contain wildcards, multiple pipeline > > stages, etc. and we did not want to push that complexity into the > > kernel fast path (nor tie it to a specific version of OpenFlow). > > Instead an exact match flow table is populated on-demand from > > userspace based on the more complex rules stored there. Although it > > might seem limiting, this design has allowed significant new > > functionality to be added without modifications to the kernel or > > performance impact. > > This can be achieved easily with zero changes to the kernel code. > You need to have default filters that redirect flows to user space > when you fail to match. Actually, this is what puts me off on the current implementation. I would prefer that the kernel implementation was just a software implementation of a hardware OpenFlow switch. That way it would be transparent that the control plane in user space was talking to kernel or hardware. > > * Packet execution: Once a flow is matched it can be output, > > enqueued to a particular qdisc, etc. Some of these operations are > > specific to Open vSwitch, such as sampling, whereas others we leverage > > existing infrastructure (including tc for QoS) by simply marking the > > packet for further processing. > > The tc classifier-action-qdisc infrastructure handles this. > The sampler needs a new action defined. There are too many damn layers in the software path already. > > * Userspace interfaces: One of the difficulties of having a > > specialized, exact match flow lookup engine is maintaining > > compatibility across differing kernel/userspace versions. This > > compatibility shows up heavily in the userspace interfaces and is > > achieved by passing the kernel's version of the flow along with packet > > information. This allows userspace to install appropriate flows even > > if its interpretation of a packet differs from the kernel's without > > version checks or maintaining multiple implementations of the flow > > extraction code in the kernel. > > I didnt quiet follow - are we talking about backward/forward > compatibility? The problem is that there are two flow classifiers, one in OpenVswitch in the kernel, and the other in the user space flow manager. I think the issue is that the two have different code. Is the kernel/userspace API for OpenVswitch nailed down and documented well enough that alternative control plane software could be built? > > It's obviously possible to put this code anywhere, whether it is an > > independent module, in the bridge, or tc. Regardless, however, it's > > largely new code that is geared towards this particular model so it > > seems better not to add to the complexity of existing components if at > > all possible. > > I am still not seeing how this could not be done without the > infrastructure that exists. Granted, the user space brains - thats where > everything else resides - but you are not pushing that i think. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
