On Thu, Jun 14, 2012 at 1:29 PM, ravi kerur <rke...@gmail.com> wrote: > 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?
This is not the userspace datapath but ofproto-dpif.c used even with the kernel datapath. The advantage is we don't have to decide on a kernel API now but it will be slow if you use those actions. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
