On 01/16/2018 01:57 PM, jianchao.wang wrote:
> Hi Max
>
> Thanks for your kindly comment.
>
> On 01/15/2018 09:36 PM, Max Gurtovoy wrote:
>>>>> case NVME_CTRL_RECONNECTING:
>>>>> switch (old_state) {
>>>>> case NVME_CTRL_LIVE:
>>>>> case NVME_CTRL_RESETTING:
>>>>> + case NVME_CTRL_RESET_PREPARE:
>>
>> I forget to add that we shouldn't move from RESET_PREPARE to RECONNECTING
>> (with my suggestion to rdma.c).
>> Also need to consider adding another check in nvmf_check_init_req
>> (/drivers/nvme/host/fabrics.h) for the new state.
>
> After Sagi's nvme-rdma: fix concurrent reset and reconnect, the rdma ctrl
> state is changed to RECONNECTING state
> after some clearing and shutdown work, then some initializing procedure, no
> matter reset work path or error recovery path.
> The fc reset work also does the same thing.
> So if we define the range that RESET_PREPARE includes scheduling gap and
> disable and clear work, RESETTING includes initializing
> procedure, RECONNECTING is very similar with RESETTING.
>
> Maybe we could do like this;
> In nvme fc/rdma
> - set state to RESET_PREPARE, queue reset_work/err_work
> - clear/shutdown works, set state to RECONNECTING
> - initialization, set state to LIVE
>
> In nvme pci
> - set state to RESET_PREPARE, queue reset_work
> - clear/shutdown works, set state to RESETTING
> - initialization, set state to LIVE
Hi Christoph, Keith, Sagi
Can you please comment on this ?
Thanks in advance.
Jianchao
