On Mon, Mar 11, 2013 at 7:22 AM, Simon Horman <[email protected]> wrote: > Hi Jesse, Hi Ben, Hi All, > > I have been working on reimplementing packet recirculation, > however I am a little unsure how to make facet revalidation work > for facets of recirculated packets. > > The problem that I am seeing is that as facets are intended to be applied > to packets that have been recirculated they may not use the odpactions of a > rule directly. Currently my implementation provides uses an offset into the > odpactions of the rule that matches the original packet (the packet before > any recirculation). And I have it in mind to change this around a little to > handle goto table by allowing the use of an offset into the odpactions of > another rule. But I'm not sure how this scheme can work with facet > revalidation. As revalidate. > > The first problem is that facet_revalidate() calls rule_dpif_lookup() > on the flow of the facet. But for the facet of recirculated packets > no such rule (should) exist. > > The second, related, problem is that facet_revalidate() calls > xlate_actions() using the looked-up rule. However the odpactions of the > rule are not the same as the odpactions used for the facet of a > recirculated packet. In cases where goto table isn't used an offset or > similar could be used. But its not clear how to cover goto table actions > correctly.
I'm not entirely sure that I'm understanding correctly but it sounds like you are planning on using a single facet to handle the processing of multiple passes of recirculation. Is that right? If so, that sounds difficult since it changes the relationship of a facet to many other pieces of the code. What if a facet still corresponded to a single pass through the datapath (and things like goto table actions would essentially stop the translation where necessary, similar how kernel patch ports effectively used to work). We could then store any data from the earlier passes along with some kind of identifier for lookup. Later translation passes would then act like normal, accessing this data like any other kind of switch softstate (similar to bond state, for example). I think revalidation would then continue to more or less work as it does today. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
