Doesn't the next patch essentially resolve this issue by making the
forwarding_if_rx calculation more responsive? With the new threaded
put stuff that's coming, we can more or less guarantee that stats will
be updated at worst once every 1.5 seconds which makes me think that
3000 seconds is overkill.
Thoughts?
Ethan
On Mon, Dec 9, 2013 at 1:40 PM, Alex Wang <al...@nicira.com> wrote:
> Currently, the ovs updates the rx_packet counter approximately every
> 2000 ms. If there is rx_packet and forwarding_if_rx is enabled, the
> forwarding_if_rx_detect_time will be incremented by 2000 ms. And as
> long as forwarding_if_rx_detect_time is greater than current time,
> the forwarding flag value is true.
>
> However, this can introduce forwarding flag flaps, when the current
> time just passes forwarding_if_rx_detect_time and some other thread
> calls bfd_forwarding() before the rx_packet counter and
> forwarding_if_rx_detect_time are updated.
>
> This commit fixes the above issue by increasing the increment of
> forwarding_if_rx_detect_time to 3000 ms. So we have 1000 ms to
> compensate for the race condition.
>
> Reported-by: Joe Stringer <joestrin...@nicira.com>
> Signed-off-by: Alex Wang <al...@nicira.com>
> ---
> lib/bfd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/bfd.c b/lib/bfd.c
> index 25129c9..4f7017d 100644
> --- a/lib/bfd.c
> +++ b/lib/bfd.c
> @@ -1105,7 +1105,7 @@ static void
> bfd_forwarding_if_rx_update(struct bfd *bfd) OVS_REQUIRES(mutex)
> {
> int64_t incr = bfd_rx_interval(bfd) * bfd->mult;
> - bfd->forwarding_if_rx_detect_time = MAX(incr, 2000) + time_msec();
> + bfd->forwarding_if_rx_detect_time = MAX(incr, 3000) + time_msec();
> bfd_forwarding__(bfd);
> }
>
> --
> 1.7.9.5
>
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
