RE: [PATCH 5/5] scsi_transport_fc: Added a new sysfs attribute noretries_abort

[Muneendra Kumar M <muneendra.kumar@broadcom.com>]

 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.