Thanks Ethan for the review,
On Fri, Aug 16, 2013 at 8:07 PM, Ethan Jackson wrote:
> This looks good to me. I have three minor comments and then it will be
> ready.
>
> 1) It doesn't seem to apply to master for me. Would you please rebase
> it and resend it?
>
I'll rebase it.
> 2) Why ar
This looks good to me. I have three minor comments and then it will be ready.
1) It doesn't seem to apply to master for me. Would you please rebase
it and resend it?
2) Why are we using 2000 milliseconds as the stat collection time? In
ofproto-dpif we're guaranteed to pull stands at least once
> There are two solutions I can think of:
> 1. use "(2000 / bfd->cfg_min_rx + 10)" to compensate for the jitter.
Sure I think this is fine as it gives us a little bit of wiggle room.
Seems a bit cleaner than option (2).
Ethan
>
>
> 2. if I can share the "push_timer" in ofproto-dpif.c with bfd.c
On Wed, Aug 14, 2013 at 7:21 PM, Ethan Jackson wrote:
> > - do not allow bfd to call bfd_may_decay when decay_min_rx
> > is less than rmt_min_tx.
>
> Why? I don't think we should need this. If the rmt_min_tx is greater
> than our min_rx, according to the bfd protocol we'll simply use the
> rm
> - do not allow bfd to call bfd_may_decay when decay_min_rx
> is less than rmt_min_tx.
Why? I don't think we should need this. If the rmt_min_tx is greater
than our min_rx, according to the bfd protocol we'll simply use the
rmt_min_tx as our rx interval (see bfd_rx_interval()). In other
word
When there is no incoming data traffic at the interface for a period,
BFD decay allows the bfd session to increase the min_rx. This is
helpful in that some interfaces may be idle for long a time. And cpu
consumption can be reduced by processing fewer bfd control packets.
Signed-off-by: Alex Wang
