On Wed, Oct 03, 2012 at 12:15:29PM -0700, Jesse Gross wrote: > On Tue, Oct 2, 2012 at 10:30 PM, Simon Horman <ho...@verge.net.au> wrote: > > On Wed, Oct 03, 2012 at 12:19:09PM +0900, Simon Horman wrote: > >> On Fri, Sep 28, 2012 at 04:20:51PM -0700, Jesse Gross wrote: > >> > On Thu, Sep 27, 2012 at 5:44 PM, Simon Horman <ho...@verge.net.au> wrote: > >> > > Do you think that adding support for multiple levels of tags to the > >> > > kernel > >> > > is appropriate. Or should such cases be bounced to user-space? > >> > > >> > The kernel should support enough tags to handle the common cases. > >> > Initially I would make this 1 but I could see it becoming 2 in the > >> > future. However, regardless of how many tags we support it's always > >> > possible that a greater number of tags are used than we support. I > >> > can see three ways to handle this: > >> > > >> > 1. Don't support it. You can run into a similar problem with vlan > >> > tags because it's possible to pop tags off and then do further > >> > operations but the kernel doesn't look deep enough into the packet. > >> > There isn't really a mechanism to deal with this today and to my > >> > knowledge nobody has actually complained. > >> > > >> > 2. Handle in userspace. It's certainly a reasonable approach for corner > >> > cases. > >> > > >> > 3. Some form of recirculation. Allowing the kernel to look at a > >> > packet, pop some tags off, and then look at it again allows processing > >> > an infinite number of tags in a manner that won't significantly affect > >> > throughput (although each round will result in more flow setups). It > >> > also allows use cases like pop MPLS tag and do IP routing, which is > >> > both fairly common and can't be realistically achieved any other way > >> > in kernel. > >> > > >> > If the short term goal is a kernel implementation, I would do #1 since > >> > it's much simpler, is a strict increase in functionality from what we > >> > have today and doesn't preclude doing #3 in the future. If you want > >> > something more complete then you can handle the extra cases using #2. > >> > > >> > If it's likely that we'll be using the userspace version for a while > >> > then it makes sense to handle all of the various cases upfront because > >> > we'll always have all of the packets and there's really no reason not > >> > to. > >> > > >> > So it depends what your goal is. > >> > >> My thinking is in terms of doing #1 then #2. > >> > >> #3 seems to add significant complexity to the kernel for corner cases. > >> If it is useful for a variety of cases then it may be worth-while, > >> but it seems to me to be overkill for MPLS alone. > > > > I have reconsidered and my current thinking is now in terms of doing #1 > > and leaving the door open for #3. > > > > With that in mind I plan to post a revised patch which implements > > the non-datapath portions for MPLS actions and matches without attempting > > to provide non-datapath implementations of those actions or matches. > > That is, a user-space portion awaiting a data-path portion. > > > > I believe this is consistent with my new thinking not to pursue #2 > > So after this patch there wouldn't be any new MPLS functionality at all? > > It seems like it would be very hard to review such a patch without a > clear plan of where it is going because many of the data structures > that it would need are different depending on what the datapath > portions look like.
Understood. > Personally, I would just start adding the basic pieces both in kernel > in userspace. A single MPLS label match certainly isn't controversial > and neither are basic push/pop actions. They can be enabled > incrementally and anything that isn't implemented yet will just be > rejected, just as all of MPLS is today. > > I'm going to post the patch that Leo gave me. It isn't complete and I > haven't reviewed it yet but I gave him the same advice so it should be > a reasonable starting point. So perhaps a good way forward would be to provide the non-datapath portions to match the (kernel) datapath portions in Leo's patch? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
