Hi James and Sagi
Thanks for your kindly response and directive.
On 01/18/2018 05:08 AM, James Smart wrote:
> On 1/17/2018 2:37 AM, Sagi Grimberg wrote:
>>
>>> After Sagi's nvme-rdma: fix concurrent reset and reconnect, the rdma ctrl
>>> state is changed to RECONNECTING state
>>> after some
Hi James and Sagi
Thanks for your kindly response and directive.
On 01/18/2018 05:08 AM, James Smart wrote:
> On 1/17/2018 2:37 AM, Sagi Grimberg wrote:
>>
>>> After Sagi's nvme-rdma: fix concurrent reset and reconnect, the rdma ctrl
>>> state is changed to RECONNECTING state
>>> after some
On 1/17/2018 2:37 AM, Sagi Grimberg wrote:
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
On 1/17/2018 2:37 AM, Sagi Grimberg wrote:
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
see V4 discussion.. :)
I didn't see any v4
see V4 discussion.. :)
I didn't see any v4
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
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
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:
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:
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
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
Hi max
Thanks for your kindly response and comment.
On 01/15/2018 09:28 PM, Max Gurtovoy wrote:
>>>
>>
>> setting RESET_PREPARE here??
>>
>> Also, the error recovery code is mutually excluded from reset_work
>> by trying to set the same state which is protected by the ctrl state
>> machine, so a
Hi max
Thanks for your kindly response and comment.
On 01/15/2018 09:28 PM, Max Gurtovoy wrote:
>>>
>>
>> setting RESET_PREPARE here??
>>
>> Also, the error recovery code is mutually excluded from reset_work
>> by trying to set the same state which is protected by the ctrl state
>> machine, so a
On 1/15/2018 3:28 PM, Max Gurtovoy wrote:
On 1/14/2018 11:48 AM, Sagi Grimberg wrote:
Currently, the ctrl->state will be changed to NVME_CTRL_RESETTING
before queue the reset work. This is not so strict. There could be
a big gap before the reset_work callback is invoked. In addition,
On 1/15/2018 3:28 PM, Max Gurtovoy wrote:
On 1/14/2018 11:48 AM, Sagi Grimberg wrote:
Currently, the ctrl->state will be changed to NVME_CTRL_RESETTING
before queue the reset work. This is not so strict. There could be
a big gap before the reset_work callback is invoked. In addition,
On 1/14/2018 11:48 AM, Sagi Grimberg wrote:
Currently, the ctrl->state will be changed to NVME_CTRL_RESETTING
before queue the reset work. This is not so strict. There could be
a big gap before the reset_work callback is invoked. In addition,
there is some disable work in the reset_work
On 1/14/2018 11:48 AM, Sagi Grimberg wrote:
Currently, the ctrl->state will be changed to NVME_CTRL_RESETTING
before queue the reset work. This is not so strict. There could be
a big gap before the reset_work callback is invoked. In addition,
there is some disable work in the reset_work
On 01/15/2018 10:11 AM, Keith Busch wrote:
> On Mon, Jan 15, 2018 at 10:02:04AM +0800, jianchao.wang wrote:
>> Hi keith
>>
>> Thanks for your kindly review and response.
>
> I agree with Sagi's feedback, but I can't take credit for it. :)
>
ahh...but sill thank you
On the other hand, welcome
On 01/15/2018 10:11 AM, Keith Busch wrote:
> On Mon, Jan 15, 2018 at 10:02:04AM +0800, jianchao.wang wrote:
>> Hi keith
>>
>> Thanks for your kindly review and response.
>
> I agree with Sagi's feedback, but I can't take credit for it. :)
>
ahh...but sill thank you
On the other hand, welcome
On Mon, Jan 15, 2018 at 10:02:04AM +0800, jianchao.wang wrote:
> Hi keith
>
> Thanks for your kindly review and response.
I agree with Sagi's feedback, but I can't take credit for it. :)
On Mon, Jan 15, 2018 at 10:02:04AM +0800, jianchao.wang wrote:
> Hi keith
>
> Thanks for your kindly review and response.
I agree with Sagi's feedback, but I can't take credit for it. :)
Hi keith
Thanks for your kindly review and response.
On 01/14/2018 05:48 PM, Sagi Grimberg wrote:
>
>> Currently, the ctrl->state will be changed to NVME_CTRL_RESETTING
>> before queue the reset work. This is not so strict. There could be
>> a big gap before the reset_work callback is invoked.
Hi keith
Thanks for your kindly review and response.
On 01/14/2018 05:48 PM, Sagi Grimberg wrote:
>
>> Currently, the ctrl->state will be changed to NVME_CTRL_RESETTING
>> before queue the reset work. This is not so strict. There could be
>> a big gap before the reset_work callback is invoked.
Currently, the ctrl->state will be changed to NVME_CTRL_RESETTING
before queue the reset work. This is not so strict. There could be
a big gap before the reset_work callback is invoked. In addition,
there is some disable work in the reset_work callback, strictly
speaking, not part of reset
Currently, the ctrl->state will be changed to NVME_CTRL_RESETTING
before queue the reset work. This is not so strict. There could be
a big gap before the reset_work callback is invoked. In addition,
there is some disable work in the reset_work callback, strictly
speaking, not part of reset
Currently, the ctrl->state will be changed to NVME_CTRL_RESETTING
before queue the reset work. This is not so strict. There could be
a big gap before the reset_work callback is invoked. In addition,
there is some disable work in the reset_work callback, strictly
speaking, not part of reset work,
Currently, the ctrl->state will be changed to NVME_CTRL_RESETTING
before queue the reset work. This is not so strict. There could be
a big gap before the reset_work callback is invoked. In addition,
there is some disable work in the reset_work callback, strictly
speaking, not part of reset work,
28 matches
Mail list logo
