[ovs-dev] Questions about a specific use-case of OVS

[Jesse Gross]

On Wed, Mar 28, 2012 at 4:30 PM, Chris Browning <chris at rurallink.co.nz> wrote:
> First, the kernel module does not support matching on multiple VLAN tags. I
> can ignore this issue for the split horizon layer 2 for the Internet and just
> match on mac address to push_vlan actions mappings, but for joining LAN's
> where I cannot guarantee the uniqueness of MAC addresses I will need to have
> the datapath aware of stacked VLAN tags and only match on those. I have heard
> that multiple people have attempted to solve this, and submitted patches, but
> nothing has been accepted. Is QinQ something that openvswitch plan to support?
> If so, is there somebody working on this that I can work with or are there any
> patches that are good place to start from and perhaps complete?

QinQ is something that we would be interested in supporting.  We
always prioritize stability and correctness over new features so while
there's been some work in this area we haven't been able to apply
anything yet.  We would certainly be happy to accept clean patches
though and you may want to search the archives for examples.

> Second, openvswitch is currently a Layer 4 aware switch (from what I have seen
> from the datapath so far). The kernel will always wonder as deep into the
> packet as it can making keys, then hash on all of the keys. This means that if
> I have an IP packet, I cannot switch purely on the mac addresses. Now
> obviously it is very easy to hack the kernel module to stop at layer 2 for me,
> but it seems more useful to configure the datapath to stop at an arbitrary
> layer, perhaps for now layers 2 or 3.  Chatting to people on your IRC channel
> it was suggested that such a patch was too specialized, and perhaps a patch
> that made all of the protocols selectable would be more appropriate. This
> doesn't seem like a hard patch, but I would love to hear your opinion.

It's possible, although I wouldn't want to reduce flexibility or
require additional configuration knobs so it would need to be handled
automatically.  I suspect that this patch may be more involved than
you realize, since it would require userspace to understand which
header fields could potentially have an effect (both directly from
flows and from functional blocks like bonding), tell the kernel that,
and track any possible changes.

> The other harder and slower approach to my problem would be allow partial
> matches on keys. I haven't thought this idea through, but the problems that
> arise in the couple of minutes I have spent thinking are, how do you know what
> keys to do the hash check on, what happens when there is a more specific match,
> and how do you do this without doing lots of hash lookups. To do it fast would
> require tree rather than a hash.

The exact match approach that we use has been very helpful in keeping
a lot of complexity in userspace, so it's not something that I would
be eager to move away from.

> Ultimately, if we could tell the datapath that we are not interested in higher
> layers, we can optimize away many trips to user-space for flows we will never
> want to see and also keep the hashes smaller, and the hash count lower. All
> making the switching more optimized for this type of use. Has the idea of
> stopping at earlier layers or protocols ever come up within the team? If we
> were to work towards implementing something like this would it be in line with
> the projects goals?

Are you actually seeing performance problems in practice or is this
just theoretical?  If it's a guess I would first run some benchmarks.
If there really are issues with flow setups, I would suggest a third
approach of optimizing the performance of the setups themselves.  I
suspect that will be the most generally useful and compatibile with
the overall feature set.