[RFC 0/7] nvme_fc: add dev_loss_tmo support

James Smart jsmart2021 at gmail.com
Thu May 4 16:17:29 PDT 2017


On 5/4/2017 2:07 PM, Christoph Hellwig wrote:
> On Thu, May 04, 2017 at 12:24:34PM -0700, James Smart wrote:
>> But, in the future, FC-NVME will support retransmission. Meaning we would
>> not immediately delete the existing association and terminate all i/o.
>> Therefore, it would be preferred if the association stays active at the
>> target at least as long as our connectivity window (if possible), and i/o
>> resumes, perhaps with retransmission to recover from errors that occurred
>> during the loss of connectivity.
>
> This is not the model the NVMe over Fabrics spec assumes.  If you want
> this model please take it to the NVMe working group first, which so far
> is left pretty much in the dark of a lot of these weird NVMe details
> anyway.
>

controller resets (CC.NE=0) would always fully reset. if the controller 
isn't reset, then the rest is simply in the retransmission model for the 
transport.

Regardless.. please ignore the KATO statements and provide feedback on 
how you think dev_loss_tmo from the transport should contend vs the 
connect option ctlr_loss_tmo.

-- james




More information about the Linux-nvme mailing list