Thomas: can you provide an example of the actions for your use case?
On Thu, Feb 25, 2016 at 01:51:22PM -0800, Jarno Rajahalme wrote: > 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
