[ovs-dev] [PATCH] revalidator: Selectively perform xlate side-effects.

[Joe Stringer]

On 24 June 2014 05:26, Alex Wang <alexw at 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?