[ovs-dev] [PATCH v2.0] Non-Datapath MPLS actions and matches

Jesse Gross jesse at nicira.com
Wed Oct 3 19:15:29 UTC 2012


On Tue, Oct 2, 2012 at 10:30 PM, Simon Horman <horms at 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 <horms at 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.

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.



More information about the dev mailing list