Re: [Suspected-Phishing]Re: [PATCH V3 1/2] nvme: split resetting state into reset_prepate and resetting

["jianchao.wang" <jianchao.w.wang@oracle.com>]

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