On Thu, Jun 14, 2012 at 9:25 AM, Pravin Shelar <pshe...@nicira.com> wrote: > On Wed, Jun 13, 2012 at 5:55 AM, Jesse Gross <je...@nicira.com> wrote: >> I spent a fair amount of time thinking about this today and concluded that >> neither option is very attractive as is. >> >> If we go with what you have now, I'm fairly confident that we will regret it >> in the future. The kernel code used to more directly implement various >> features and prior to upstreaming we broke many of them down. I'm happy >> with the results of that but this time we won't have the benefit of revising >> things later. This is particularly bad because it deviates from our usual >> model of userspace controlling everything and here userspace won't even know >> what the flow looks like. The effects of this tend to metastasize because >> when userspace doesn't know what the packet looks like it can't implement >> things that it might overwise be able to do and more and more ends up in the >> kernel. The other thing, which is specific to MPLS, is that there is no >> inherent way to know the type of the payload. Userspace is vastly more >> likely to have this information in the event that we want to do something >> with the inner packet. In your patch the kernel is basically assuming that >> the type is IP (OpenFlow doesn't give us any additional information but it >> doesn't seem like a good idea in general). >> > For now we can implement ttl_in and ttl_out only in userspace by not > installing flow if these are not very common actions used.
That may make sense for the time being. In some use cases the TTL operations might get used a lot but there are plenty of others where MPLS could be used without them. If we decide to go down the recirculation path, that's a fairly big project, so doing some operations in userspace may allow MPLS to continue moving forward. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
