Hi Hannes, >> >> Hmm. Wouldn't it make more sense to introduce a new port state 'marginal' >> for this? We might >want/need to introduce additional error recovery >> mechanisms here, so having a new state >might be easier in the long run >> ... > >> Additionally, from my understanding the FPIN events will be generated >> with a certain >frequency. So we could model the new 'marginal' state >> similar to the dev_loss_tmo >mechanism; start a timer whenever the >> 'marginal' state is being set, and clear the state back to >'running' >> if the state hasn't been refreshed within that timeframe. >> That would give us an automatic state reset back to running, and >> quite easy to implement from >userland. > > Thanks for the review. > I have a small doubt. > When the port state moves from marginal to running state does it mean > we expect a traffic from the path ? > >We don't expect traffic; rather we _allow_ traffic. >But moving to from marginal to running means that we didn't receive FPIN >events, and the path should be considered healthy again. >So from that perspective it should be back to normal operations. But this could apply only to FPIN-Congestion. Only in this case FPIN-CN FPIN events will be generated with a certain frequency. But for FPIN-Li this is not the case. FPIN-LI is used to inform about marginal paths, which needs manual intervention to recover. And for FPIN-LI the path should be re-enabled on any link bounce (portdisable followed by portenable) which would correlated to a cable/sfp change. For now, however, we are addressing FPIN-LI primarily. Regards, Muneendra.
