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.. (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. (d) We will allocate a new xcache, which is only kept for flows that we are about to delete. I don't understand the motivation for this. Consider a flow with output:1, which is invalid and should be replaced with a flow that outputs to 2. If more packets arrive between dumping the flow, revalidating, and finally deleting the flow, then these stats will be attributed to the new rule. However, the datapath would have already forwarded using the old rule. - in push_dump_ops__(), could we just push stats (skip the side-effects) > after > deleting the flow? This may require us to never miss dump flow from dp. > This becomes difficult to argue either way. If the OVS is under high load, it will attempt to avoid revalidation for low-throughput flows, so many flows may end up being deleted (with packets attributed and side-effects) in the flow deletion logic. Depending on how the rules are configured, and on the traffic patterns, performing side-effects here may make things better or worse. Is there a particular case you have in mind that this may help? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
