[lkml]   [2018]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Suspected-Phishing]Re: [PATCH V3 1/2] nvme: split resetting state into reset_prepate and resetting

On 01/16/2018 01:57 PM, 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.


 \ /
  Last update: 2018-01-16 08:53    [W:0.078 / U:2.332 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site