On Thu, Sep 5, 2013 at 6:20 PM, Simon Horman <ho...@verge.net.au> wrote: > Hi Jesse, > > I have been looking at updating the recirculation implementation for > currently merged multi-threaded miss handling and planned changes by > Ethan to remove facts from ovs-vswtichd. I would like this chance to > thank Ethan for sharing his plans with me in some detail, it has been > very helpful. > > While I believe it is possible to implement the current design on > top of the new code I wonder if it is a good time to pause and consider > tweaking the design. > > The main area of difficulty I see with implementing the current design > on the new code-base hinges around the use of recirculation ids. > > In particular when handling a miss for a recirculated packet the > recirculation id is used to allow the rule that recirculated the packet to > be found. And then for processing of the actions of that rule to continue > on the recirculated packet. This requires some state to be stored in > ovs-vswtichd. If facets exist in ovs-vswitchd then this state fits fairly > nicely in the facet. But in the absence of facets, it seems to me that the > state would need to be stored in some new data structure. And that seems > likely to re-introduce a subset of the problems resolved by Ethan's plan to > remove facets from ovs-vswtichd. > > With this in mind I wonder if an alternate approach would be for the > datapath to pass all information that ovs-vswtichd needs to process a > recirculated packet when it makes an upcall. I'm not entirely sure but it > seems that this could be achieved by passing the key (and probably mask) of > the chain of packets that lead to the upcall. In short, instead of passing > a recirculation_id pass a as part of the upcall's flow, pass nested flows. > > Although I suspect this would be a rather invasive change to several areas > of the code and may involve some extra cost in the datapath when processing > recirculation - a copy of the flow may need to be kept at each level of > recirculation - it does seem to be more in keeping with the direction in > which Ethan's plans are taking ovs-vswtichd.
I think this is probably possible although I'm not sure that it actually saves all that much. Since the key is fairly big (a few hundred bytes), it seems like we would need some kind of new data structure to track it outside of the packet. That almost sounds like a kernel-side facet to me. My inclination is to use essentially the same type of structure as what you currently have but rather than piggy-back off of the existing facet code, have a more limited data structure when recirculation is in use. There will probably be a few features that requires this type of cache but my hope is that they will be easier to optimize for concurrent access because they are much more limited in scope. The other benefit is that there won't be a split between governor and non-governor cases. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
