On Fri, Mar 22, 2013 at 6:44 AM, Simon Horman <ho...@verge.net.au> wrote: > On Tue, Mar 19, 2013 at 09:01:27AM -0700, Jesse Gross wrote: >> On Mon, Mar 18, 2013 at 6:34 PM, Simon Horman <ho...@verge.net.au> wrote: >> > On Mon, Mar 18, 2013 at 01:49:43PM -0700, Jesse Gross wrote: >> >> However, do we actually want to tie this directly to recirculation as >> >> opposed to as a separate action? I see possible benefits of >> >> separating it out: >> > >> > I'm not really sure that I understand. Could you explain >> > how you see this working? >> >> Just a set action plus recirculation with no argument. Separating out >> the issues of reusing skb mark, this could be done today with >> something like: >> pass 1: match MPLS -> pop_mpls, set(mark(X)), recirculate >> pass 2: match mark X, match MPLS -> pop_mpls, recirculate >> pass 3: match mark X, match IP -> output > > Thanks, I have a crude implementation of this working locally. > > I'm not sure what the implications are for the user-space datapath. > Though that is less of a priority for me than the kernel datapath.
I think we could probably just add some kind of mark equivalent to the userspace datapath. It doesn't seem like it should be too difficult. > I am also concerned, though less so, about: > > * How to handle packet_out. Perhaps some kind of synthetic facet? > * How to detect if recirculation will occur and thus force > a miss to be handled with a facet. For now I am just checking > if the packet MPLS or not, but it would be nice not to force facets > unless necessary. Actually, it would be nice not to force the > use of facets at all. Long term, the right optimization is probably to handle all recirculation in userspace for these cases. It will certainly help performance in situations without facets since that means that we're already stressed on flow setups and it would be good to not generate more trips through the kernel. However, for the time being the best strategy seems like some kind of delayed allocation of facets to the time that we decide to do recirculation (unless we were going to create one anyways). _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
