Maybe going back to the design where we have a separate function analyzing the current action in case of “deferred recirculation” (== unmatchable struct flow) would be the best compromise. I recall I did not like that earlier, but it might be best option if recirculation between MPLS_POP and non-table OUTPUT cannot be tolerated.
Jarno > On Feb 25, 2016, at 10:36 AM, Ben Pfaff <b...@ovn.org> wrote: > > On Thu, Feb 25, 2016 at 06:05:06PM +0100, Thomas Morin wrote: >> Hi Ben, >> >> 2016-02-25, Ben Pfaff: >>> On Thu, Feb 25, 2016 at 10:26:28AM +0100, thomas.mo...@orange.com wrote: >>>> Sorry to chime in a bit late, but this recirculation performance penalty >>>> for >>>> the basic/key use-case where OVS receives an IP-in-MPLS frame and forwards >>>> it to the destination (e.g. a local VM), does not look appealing at all. >>>> >>>> To allow having the best of both worlds (avoid perf penalty in all cases, >>>> but avoid complex code to automatically determine whether recirculation is >>>> needed or not), would it be possible to specify in a flow, after an mpls >>>> match, whether or not recirculation is wanted ? >>> >>> No. That would be a layering violation. >> >> I don't get what kind of layering violation you see. >> Can you explain? > > Whoever specifies the actions shouldn't have to know OVS implementation > details. Having to know whether recirculation is necessary means that > the user must know all about the implementation. > > Also, the "pop MPLS" action is specified by OpenFlow and doesn't include > this information. > >>> If you can find a better way to do it, that is maintainable, we'd be >>> open to that. >> >> What about: >> - adding a parameter to the pop_action (recirculate after pop, or don't >> recirculate after pop) > > The "pop MPLS" action is specified by OpenFlow and doesn't include this > information. > >> - or keep the current pop, and add a pop_and_do_not_recirculate > > Possibly, if you can specify pop_and_do_not_recirculate in a way that > refers only to stuff that makes sense at the OpenFlow level, so it makes > sense without having to refer to OVS implementation details. It's not a > perfect solution, but it might be acceptable if nothing better can be > found. > >> - or add an explicit recirculate action, and by default do not recirculate > > Layering violation. > _______________________________________________ > dev mailing list > dev@openvswitch.org <mailto:dev@openvswitch.org> > http://openvswitch.org/mailman/listinfo/dev > <http://openvswitch.org/mailman/listinfo/dev> _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
