[ovs-dev] [PATCH 2/2] revalidator: Complain for more ukey transitions.

Jarno Rajahalme jarno at ovn.org
Wed Jan 11 00:02:42 UTC 2017


In the worst case this patch will introduce rate-limited logging for other states than UKEY_OPERATIONAL that may want to transition onto themselves, so:

Acked-by: Jarno Rajahalme <jarno at ovn.org>

> On Jan 10, 2017, at 3:54 PM, Joe Stringer <joe at ovn.org> wrote:
> 
> For most ukey transition states, only one thread should be responsible
> for transitioning the ukey into the new state. If another thread
> attempts to transition the ukey into the same state (for instance,
> evicting the datapath flow or deleting the ukey), then it is likely
> performing additional work which should only happen once. Log all cases
> of ukey transition into the current state, except for UKEY_OPERATIONAL
> -> UKEY_OPERATIONAL which regularly occurs when revalidating ukeys.
> 
> Signed-off-by: Joe Stringer <joe at ovn.org>
> ---
> ofproto/ofproto-dpif-upcall.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
> index 1ffeaabf7d8e..660383faee1c 100644
> --- a/ofproto/ofproto-dpif-upcall.c
> +++ b/ofproto/ofproto-dpif-upcall.c
> @@ -1672,7 +1672,7 @@ transition_ukey(struct udpif_key *ukey, enum ukey_state dst)
>     OVS_REQUIRES(ukey->mutex)
> {
>     ovs_assert(dst >= ukey->state);
> -    if (ukey->state == dst) {
> +    if (ukey->state == dst && dst == UKEY_OPERATIONAL) {
>         return;
>     }
> 
> -- 
> 2.10.2
> 



More information about the dev mailing list