linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: brking@linux.vnet.ibm.com
Cc: "linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>,
	James Bottomley <James.Bottomley@SteelEye.com>
Subject: Re: [RFC 0/3] [SCSI/libata] libata EH conversion for ipr SAS
Date: Tue, 30 Oct 2007 10:04:49 -0400	[thread overview]
Message-ID: <47273A01.6010604@garzik.org> (raw)
In-Reply-To: <47263F85.70908@linux.vnet.ibm.com>

Brian King wrote:
> The following three patches convert ipr to use the new libata EH APIs.
> In the process of doing this, I first looked into implementing this
> in a similar manner to how libata SAS is done today, which is hooking
> into target_alloc/target_destroy to allocate/delete sata ports. While
> I was able to get this working after writing my own eh_strategy_handler,
> I was doubtful this was the best long term solution. One problem with this
> implementation I didn't solve was the fact that libata now invokes EH
> for each and every error received. For some devices, such as optical
> devices, each not ready response received during a media reload would
> result in all the attached SAS devices getting quiesced as well.
> 
> My second approach is the attached patch set. In this series I have
> created a new libata API which can be used by SAS LLDDs. It introduces
> an ata_sas_rphy device object which is created/destroyed by the following API:
> 
> ata_sas_rphy_alloc
> ata_sas_rphy_add
> ata_sas_rphy_delete
> 
> When using this API in ipr, I made ipr's scsi_host the parent device of the
> SATA rphy. The SATA rphy is then the parent of the allocated scsi_hosts. This
> means that each SATA rphy in the SAS topology will have its own scsi_host, making
> SAS *much* more like all the SATA LLDDs in how it uses libata.
> 
> The only issue I ran into with this implementation is that since each SATA
> port has its own scsi_host, the adapter cannot rely on scsi core to manage
> any LLDD or adapter imposed queue depth. To solve this I added some code to
> ipr. Longer term, block layer queue groups might be another way to do this.
> 
> I'm still polishing this up, but it is up and running and seems to work with
> what testing I've done so far.

Like I said on IRC... thanks for taking care of this!  After this we are 
down to three old-EH users:  libsas, sata_qstor (patch exists, waiting 
on testing) and sata_sx4 (patch exists, waiting on testing).

I'll take a good look in the next day or so.  Overall the coupling 
between SAS (ipr and libsas) and libata definitely needs some thought.

	Jeff




  parent reply	other threads:[~2007-10-30 14:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-29 20:16 [RFC 0/3] [SCSI/libata] libata EH conversion for ipr SAS Brian King
2007-10-29 20:18 ` [RFC 1/3] " Brian King
2007-10-29 20:19   ` [RFC 2/3] " Brian King
2007-10-29 20:21     ` [RFC 3/3] ipr: Use new libata EH API Brian King
2007-10-30 14:04 ` Jeff Garzik [this message]
2007-11-24  1:06 ` [RFC 0/3] [SCSI/libata] libata EH conversion for ipr SAS Jeff Garzik

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=47273A01.6010604@garzik.org \
    --to=jeff@garzik.org \
    --cc=James.Bottomley@SteelEye.com \
    --cc=brking@linux.vnet.ibm.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-scsi@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).