On Wed, 2016-08-03 at 23:04 +0200, Richard Cochran wrote: > On Tue, Aug 02, 2016 at 10:08:04PM +0000, Keller, Jacob E wrote: > > > > Here? Wouldn't these two port dispatch things be racing with the > > ones > > above? > > I don't think the link events will spoil the existing timeouts. Here > are the currently defined fault types.
Hmm. Ok, it just seems like you call port_dispatch with FAULT_CLEARED when link goes up. The commit message says "we will keep the old fault handling and won't clear the fault while link is down." but this new flow seems to me to actually prevent the full wait because we'll clear the fault once we go back up. I guess it's just a mis-read of the commit message. For sure, we will *stay* in fault as long as the link is still down (good). But if the link goes up before the fault timeout ends, we'll just clear the fault and reset. I think this behavior is an improvement since it will allow a link-down/link-up to clear faster. It just wasn't clear from the commit mesage to me. > There is one case where the new code changes the existing behavior. > If the link quickly does down and then up again while another fault > (and its timer) are active, then we will enter the UP state without > waiting for the fault timer expiration. However, I consider this > behavior acceptable, because when a link goes up, you are starting > from with a clean slate. Even the network might have changed, so the > FT_BAD_PEER_NETWORK fault is then dubious. > Hmm. I think the commit message seems to indicate that we wouldn't clear faults in the link up case. But I think I agree with the logic here, this is definitely an improvement over the previous situation and clearing the state and going up makes sense to me. > I would welcome even more comprehensive fault handling, if some one > wants to code it. But having this more intelligent link handling is > an improvement and at least a step in the right direction, IMHO. > > Thoughts? > It's worth thinking about for the future, but what we have now should be an improvement. Regards, Jake > Thanks, > Richard > ------------------------------------------------------------------------------ _______________________________________________ Linuxptp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
