On Mon, Jun 23, 2014 at 6:10 PM, Joe Stringer <joestrin...@nicira.com> wrote:
> On 24 June 2014 05:26, Alex Wang <al...@nicira.com> wrote: > >> (snip) >> >> Totally agree, >> >> So, I'm thinking this solution, >> >> - in revalidate_ukey(), if need_revalidate is set, we always: >> 1. save the current xcache to old_xcache pointers. >> 2. conduct full revalidation (but never push stats during revalidation) >> and >> get a new xcache. >> 3.1. if the ukey is the same, delete the new xcache and push >> stats/side-effects. >> 3.2. if the ukey is different, only push stats to old_xcache. delete the >> old_xcache, and save the pointer to new xcache. >> > > If I follow correctly, the logic you specify: > > (a) Stats are always pushed using the old xcache. > I think this is consistent with the current patch. > > (b) Side-effects are only pushed if revalidation passes, and using the old > xcache. > The main difference between this and the current patch, is this suggests > using the old xcache rather than the new one. However.. > Yes, your understanding is correct. > (c) If the higher layer state changes, but the ukey remains the same, we > will always use the old xcache. > This is a possibility for eg, flows with a learn action that doesn't > affect its own pipeline. Using the old xcache may trigger learn actions > that have been removed from the flow table. Failing to replace the xcache > could cause this old state to hang around and cause incorrect flow learning > for a long time. > > I agree with your analysis. Based on the discussion offline, there is really no good answer to the question. We think it is least wrong to always try attributing the stats/side-effects to new userspace OpenFlow pipeline. We will reconsider the issue after Joe's ukey/xcache creation in userspace work. Thanks, Alex Wang, _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
