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 ? Regards, Muneendra.
