Thanks Jesse, I will have a look through the archives to find previous submitted patches for QinQ.
As for the layered flow matching, you are right, I have been looking at it from a purely theoretical point of view. Once I progress my trial a bit further I will replay some real traffic traces through the switch and observe the load, hack the kernel path to layer 2 only and replay the same trace again and compare results. Cheers, Chris On Thu, 29 Mar 2012 15:50:50 Jesse Gross wrote: > On Wed, Mar 28, 2012 at 4:30 PM, Chris Browning <ch...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
