On Wed, Jun 13, 2012 at 8:21 PM, Jesse Gross <je...@nicira.com> wrote: > 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.
<rk> are you referring to ttl actions to be implemented in userspace only? if that's case how will it solve the problem? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
