All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Smart <James.Smart@emulex.com>
To: Ren Mingxin <renmx@cn.fujitsu.com>
Cc: James.Bottomley@HansenPartnership.com,
	Nagalakshmi.Nandigama@lsi.com, Sreekanth.Reddy@lsi.com,
	michaelc@cs.wisc.edu, robert.w.love@intel.com,
	dgilbert@interlog.com, hare@suse.de, bprakash@broadcom.com,
	agk@redhat.com, neilb@suse.de, gregkh@linuxfoundation.org,
	axboe@kernel.dk, tj@kernel.org, linux-kernel@vger.kernel.org,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH 0/5] scsi: Allow fast io fail without waiting through timeout
Date: Wed, 22 May 2013 14:04:45 -0400	[thread overview]
Message-ID: <519D08BD.9080103@emulex.com> (raw)
In-Reply-To: <519C6FD6.4090607@cn.fujitsu.com>

yes - that was the session. Granted the posted notes were rather terse.

More of the ideas were presented in this recent email thread: 
http://marc.info/?l=linux-scsi&m=136819142000596&w=2

In general - we're going to create a LLD library for error handling, 
using paradigms in libsas, that:
- no longer stops the whole host on the 1st error and doesn't start 
error handling till all outstanding io is finished/timedout
- sends per-io aborts immediately, and in parallel. LLD handlers will be 
asynchronous.
- no lun/target will be stopped until i/o aborts start to fail.
- do smart handling of lun resets, target resets, bus resets, etc and 
don't potentially do it for every i/o.

Several of these topics were touched on in the email thread.

the patches are being worked on now - hopefully to be posted as an RFC 
within the next couple of weeks.

-- james s



On 5/22/2013 3:12 AM, Ren Mingxin wrote:
> Hi, James,
>
> On 05/20/2013 11:53 PM, James Smart wrote:
>> Based on the discussion recently held at LSF 2013, we are
>> reworking the error recovery path to address all the issues
>> you are mentioning. That work contradicts these patches.
>> So for now, these should be held off.
>
> Interesting. Can I have your general goal/idea briefly even
> though via a reference? Will the URL below be one you will
> refer to?
>   http://lwn.net/Articles/548500
>
> And, could I know your current progress/schedule? Especially
> when can we see your patches?
>
> Much appreciated!
>
> Thanks,
> Ren
>
>>
>> On 5/20/2013 3:14 AM, Ren Mingxin wrote:
>>> When there is a scsi command timed-out or failed, the scsi eh
>>> tries a thorugh recovery, which is necessary for non-redundant
>>> systems. However, the thorugh recovery usually takes much time,
>>> which is not acceptable for misson critical systems. To improve
>>> this latency, if we are working on a redundant system, we should
>>> avoid the scsi eh for its long time failing recovery, and quick
>>> failover to another path.
>>>
>>> This set of patches is trying to implement above.
>>>
>>> NOTE: the userland tools need to eusure the environment
>>> restriction, which will be implemented later.
>>>
>>> Thanks,
>>> Ren
>>>
>>> Ren Mingxin (5):
>>>    scsi: rename return code FAST_IO_FAIL to FAST_IO
>>>    FC transport: Add interface to specify fast io level for 
>>> timed-out cmds
>>>    SAS transport: Add interface to specify fast io level for 
>>> timed-out cmds
>>>    lpfc: Allow fast timed-out io recovery
>>>    mptfusion: Allow fast timed-out io recovery
>>>
>>>   drivers/message/fusion/mptscsih.c   |   29 ++++++++-
>>>   drivers/scsi/lpfc/lpfc_scsi.c       |   34 ++++++++++
>>>   drivers/scsi/scsi_error.c           |   18 ++---
>>>   drivers/scsi/scsi_sas_internal.h    |    4 -
>>>   drivers/scsi/scsi_transport_fc.c    |  112 
>>> ++++++++++++++++++++++++++++++++++--
>>>   drivers/scsi/scsi_transport_iscsi.c |    6 -
>>>   drivers/scsi/scsi_transport_sas.c   |  103 
>>> ++++++++++++++++++++++++++++++++-
>>>   include/scsi/scsi.h                 |    2
>>>   include/scsi/scsi_transport_fc.h    |   11 +++
>>>   include/scsi/scsi_transport_sas.h   |    8 ++
>>>   10 files changed, 303 insertions(+), 24 deletions(-)
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

WARNING: multiple messages have this Message-ID (diff)
From: James Smart <James.Smart@emulex.com>
To: Ren Mingxin <renmx@cn.fujitsu.com>
Cc: <James.Bottomley@HansenPartnership.com>,
	<Nagalakshmi.Nandigama@lsi.com>, <Sreekanth.Reddy@lsi.com>,
	<michaelc@cs.wisc.edu>, <robert.w.love@intel.com>,
	<dgilbert@interlog.com>, <hare@suse.de>, <bprakash@broadcom.com>,
	<agk@redhat.com>, <neilb@suse.de>, <gregkh@linuxfoundation.org>,
	<axboe@kernel.dk>, <tj@kernel.org>,
	<linux-kernel@vger.kernel.org>, <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH 0/5] scsi: Allow fast io fail without waiting through timeout
Date: Wed, 22 May 2013 14:04:45 -0400	[thread overview]
Message-ID: <519D08BD.9080103@emulex.com> (raw)
In-Reply-To: <519C6FD6.4090607@cn.fujitsu.com>

yes - that was the session. Granted the posted notes were rather terse.

More of the ideas were presented in this recent email thread: 
http://marc.info/?l=linux-scsi&m=136819142000596&w=2

In general - we're going to create a LLD library for error handling, 
using paradigms in libsas, that:
- no longer stops the whole host on the 1st error and doesn't start 
error handling till all outstanding io is finished/timedout
- sends per-io aborts immediately, and in parallel. LLD handlers will be 
asynchronous.
- no lun/target will be stopped until i/o aborts start to fail.
- do smart handling of lun resets, target resets, bus resets, etc and 
don't potentially do it for every i/o.

Several of these topics were touched on in the email thread.

the patches are being worked on now - hopefully to be posted as an RFC 
within the next couple of weeks.

-- james s



On 5/22/2013 3:12 AM, Ren Mingxin wrote:
> Hi, James,
>
> On 05/20/2013 11:53 PM, James Smart wrote:
>> Based on the discussion recently held at LSF 2013, we are
>> reworking the error recovery path to address all the issues
>> you are mentioning. That work contradicts these patches.
>> So for now, these should be held off.
>
> Interesting. Can I have your general goal/idea briefly even
> though via a reference? Will the URL below be one you will
> refer to?
>   http://lwn.net/Articles/548500
>
> And, could I know your current progress/schedule? Especially
> when can we see your patches?
>
> Much appreciated!
>
> Thanks,
> Ren
>
>>
>> On 5/20/2013 3:14 AM, Ren Mingxin wrote:
>>> When there is a scsi command timed-out or failed, the scsi eh
>>> tries a thorugh recovery, which is necessary for non-redundant
>>> systems. However, the thorugh recovery usually takes much time,
>>> which is not acceptable for misson critical systems. To improve
>>> this latency, if we are working on a redundant system, we should
>>> avoid the scsi eh for its long time failing recovery, and quick
>>> failover to another path.
>>>
>>> This set of patches is trying to implement above.
>>>
>>> NOTE: the userland tools need to eusure the environment
>>> restriction, which will be implemented later.
>>>
>>> Thanks,
>>> Ren
>>>
>>> Ren Mingxin (5):
>>>    scsi: rename return code FAST_IO_FAIL to FAST_IO
>>>    FC transport: Add interface to specify fast io level for 
>>> timed-out cmds
>>>    SAS transport: Add interface to specify fast io level for 
>>> timed-out cmds
>>>    lpfc: Allow fast timed-out io recovery
>>>    mptfusion: Allow fast timed-out io recovery
>>>
>>>   drivers/message/fusion/mptscsih.c   |   29 ++++++++-
>>>   drivers/scsi/lpfc/lpfc_scsi.c       |   34 ++++++++++
>>>   drivers/scsi/scsi_error.c           |   18 ++---
>>>   drivers/scsi/scsi_sas_internal.h    |    4 -
>>>   drivers/scsi/scsi_transport_fc.c    |  112 
>>> ++++++++++++++++++++++++++++++++++--
>>>   drivers/scsi/scsi_transport_iscsi.c |    6 -
>>>   drivers/scsi/scsi_transport_sas.c   |  103 
>>> ++++++++++++++++++++++++++++++++-
>>>   include/scsi/scsi.h                 |    2
>>>   include/scsi/scsi_transport_fc.h    |   11 +++
>>>   include/scsi/scsi_transport_sas.h   |    8 ++
>>>   10 files changed, 303 insertions(+), 24 deletions(-)
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


  reply	other threads:[~2013-05-22 18:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-20  7:14 [PATCH 0/5] scsi: Allow fast io fail without waiting through timeout Ren Mingxin
2013-05-20  7:14 ` [PATCH 1/5] scsi: rename return code FAST_IO_FAIL to FAST_IO Ren Mingxin
2013-05-20  7:15 ` [PATCH 2/5] FC transport: Add interface to specify fast io level for timed-out cmds Ren Mingxin
2013-05-20  7:15 ` [PATCH 3/5] SAS " Ren Mingxin
2013-05-20  7:15 ` [PATCH 4/5] lpfc: Allow fast timed-out io recovery Ren Mingxin
2013-05-20  7:15 ` [PATCH 5/5] mptfusion: " Ren Mingxin
2013-05-20 15:53 ` [PATCH 0/5] scsi: Allow fast io fail without waiting through timeout James Smart
2013-05-20 15:53   ` James Smart
2013-05-22  7:12   ` Ren Mingxin
2013-05-22 18:04     ` James Smart [this message]
2013-05-22 18:04       ` James Smart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=519D08BD.9080103@emulex.com \
    --to=james.smart@emulex.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=Nagalakshmi.Nandigama@lsi.com \
    --cc=Sreekanth.Reddy@lsi.com \
    --cc=agk@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=bprakash@broadcom.com \
    --cc=dgilbert@interlog.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hare@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    --cc=neilb@suse.de \
    --cc=renmx@cn.fujitsu.com \
    --cc=robert.w.love@intel.com \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.