I understand code review is time consuming and please note it's a bit time consuming to me as well as I have to retest/rebase everytime and I am not sure whether the amount of time I am spending on this is justifiable?
MPLS actions are implemented as per section 4.8 in OF 1.1 specification, excerpts below "The Apply-Actions instruction and the Packet-out message include an action list. The semantic of the action list is identical to the OpenFlow 1.0 specification. The actions of an action list are executed in the order specified by the list, and are applied immediately to the packet." I looked at implementing ttl actions as set operations and didn't find it suitable as every ttl action is applied immediately and it won't integrate well with other mpls actions(push/pop and set label) which are applied immediately. Please note there can be more than 2 mpls push and pop actions configured. With respect to packet recycling I thought it was for handling layer-3 after executing mpls actions or could be generic purpose as well but focused on inner-header parsing or further actions executed based on inner-header after applying actions to outer-header. Packet recycling for ttl operations looks like an overkill to me as you might be aware that packet recycling has performance impact. On Mon, Jul 2, 2012 at 7:15 PM, Jesse Gross <je...@nicira.com> wrote: > On Sat, Jun 30, 2012 at 8:56 AM, ravi kerur <rke...@gmail.com> wrote: >> Can you take a look at latest diffs I sent out on Tuesday? It has >> simplified ttl handling for both userspace and kernel datapath. Most >> of the logic is in ofproto-dpif.c and datapath just updates ttl in the >> packet for respective headers. This is the minimal operation any >> datapath will do irrespective of where the complexity is. > > I do look at your patches, including this one. It takes time both to > review them and to think about what direction I think it should be > going. Please do not assume otherwise. > > Your patch does not address any of the concerns that I had before. > Moving some of the logic to userspace is not helpful as long as it > still requires the original code to be present in the kernel. It's > also not the simplest possible implementation given that I have > mentioned two potential alternatives that would entail less datapath > code. > >> Its still unclear to me why ttl operations would need packet recirculation? > > I described my concerns about the different approaches here: > http://openvswitch.org/pipermail/dev/2012-June/017834.html
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
