On Mon, Mar 11, 2013 at 06:28:35PM -0700, Jesse Gross wrote: > 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.
I think that is more or less what my code does, a separate facet for each pass and an identifier. There is an identifier and I think it can be used to save the first problem, thanks. I am, however, still unsure what to do about the second problem above. If a rule changes it may well be the case that the facet of a secondary pass of a recirculated packet becomes invalid. But it seems there may not be a rule available to verify that. I'll take a look at bond state for some insights. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
