Re: [PATCH 5/6] hisi_sas: add hisi_sas_slave_configure()

[John Garry]

On 18/02/2016 10:57, John Garry wrote:
> On 18/02/2016 10:30, Hannes Reinecke wrote:
> > On 02/18/2016 11:12 AM, John Garry wrote:
> > > On 18/02/2016 07:40, Hannes Reinecke wrote:
> > [ .. ]
> > > > Well, the classical thing would be to associate each request tag
> > > > with a SAS task; or, in your case, associate each slot index with a
> > > > request tag.
> > > > You probably would need to reserve some slots for TMFs, ie you'd
> > > > need to decrease the resulting ->can_queue variable by that.
> > > > But once you've done that you shouldn't hit any QUEUE_FULL issues,
> > > > as the block layer will ensure that no tags will be reused while the
> > > > command is in flight.
> > > > Plus this is something you really need to be doing if you ever
> > > > consider moving to scsi-mq ...
> > > >
> > > > Cheers,
> > > >
> > > > Hannes
> > > Hi,
> > >
> > > So would you recommend this method under the assumption that the
> > > can_queue value for the host is similar to the queue depth for the
> > > device?
> > That depends.
> > Typically the can_queue setting reflects the number of commands the
> > _host_ can queue internally (due to hardware limitations etc).
> > They do not necessarily reflect the queue depth for the device
> > (unless you have a single device, of course).
> > So if the host has a hardware limit on the number of commands it can
> > queue, it should set the 'can_queue' variable to the appropriate
> > number; a host-wide shared tag map is always assumed with recent
> > kernels.
> >
> > The queue_depth of an individual device is controlled by the
> > 'cmd_per_lun' setting, and of course capped by can_queue.
> >
> > But yes, I definitely recommend this method.
> > Is saves one _so much_ time trying to figure out which command slot
> > to use. Drawback is that you have to have some sort of fixed order
> > on them slots to do an efficient lookup.
> >
> > Cheers,
> >
> > Hannes
>
> I would like to make a point on cmd_per_lun before considering tagging
> slots: For our host the can_queue is considerably greater than
> cmd_per_lun (even though we initially set the same in the host template,
> which would be incorrect). Regardless I find the host cmd_per_lun is
> effectively ignored for the slave device queue depth as it is reset in
> sas_slave_configure() to 256 [if this function is used and tagging
> enabled]. So if we we choose a reasonable cmd_per_lun for our host, it
> is ignored, right? Or am I missing something?
>
> Thanks,
> John

I would like to make another point about why I am making this change in 
case it is not clear. The queue full events are form 
TRANS_TX_CREDIT_TIMEOUT_ERR and TRANS_TX_CLOSE_NORMAL_ERR errors in the 
slot: I want the slot retried when this occurs, so I set status as 
SAS_QUEUE_FULL just so we will report DID_SOFT_ERR to SCSI midlayer so 
we get a retry. I could use SAS_OPEN_REJECT alternatively as the error 
which would have the same affect.
The queue full are not from all slots being consumed in the HBA.

thanks again,
John


> _______________________________________________
> linuxarm mailing list
> linuxarm@xxxxxxxxxx
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm