On Mon, Mar 11, 2013 at 11:46 PM, Simon Horman <[email protected]> wrote: > 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.
I think you can tag library (which is basically a bloom filter) to detect flows that may potentially be affected by a change and need to be revalidated. This is how bonds know which flows to update on failover or MAC learning updates flows after learning a new address. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
