From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1426059AbcBRKNm (ORCPT ); Thu, 18 Feb 2016 05:13:42 -0500 Received: from szxga02-in.huawei.com ([119.145.14.65]:27184 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1425279AbcBRKNh (ORCPT ); Thu, 18 Feb 2016 05:13:37 -0500 Subject: Re: [PATCH 5/6] hisi_sas: add hisi_sas_slave_configure() To: Hannes Reinecke , , References: <1455625351-165881-1-git-send-email-john.garry@huawei.com> <1455625351-165881-6-git-send-email-john.garry@huawei.com> <56C34163.70606@suse.de> <56C354A5.6080503@huawei.com> <56C5756A.9060700@suse.de> CC: , , , , , From: John Garry Message-ID: <56C59922.6070600@huawei.com> Date: Thu, 18 Feb 2016 10:12:50 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C5756A.9060700@suse.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.203.181.155] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56C5993E.0183,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c1148716548265bfbdbce1a9415be508 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18/02/2016 07:40, Hannes Reinecke wrote: > On 02/16/2016 05:56 PM, John Garry wrote: >> On 16/02/2016 15:33, Hannes Reinecke wrote: >>> On 02/16/2016 01:22 PM, John Garry wrote: >>>> In high-datarate aging tests, it is found that >>>> the SCSI framework can periodically >>>> issue lu resets to the device. This is because scsi >>>> commands begin to timeout. It is found that TASK SET >>>> FULL may be returned many times for the same command, >>>> causing the timeouts. >>>> To overcome this, the queue depth for the device needs >>>> to be reduced to 64 (from 256, set in >>>> sas_slave_configure()). >>>> >>> Hmm. TASK SET FULL should cause the queue depth to be reduced >>> automatically, no? >>> >>> Cheers, >>> >>> Hannes >>> >> >> I need to double-check if Task set full reduces the depth, I don't >> think it does. >> >> Regardless I found we were getting a combination of commands being >> retried due to Task Set Full and also SAS_QUEUE_FULL errors. For >> sure the SAS_QUEUE_FULL task errors reduce the queue depth in >> scsi_track_queue_full(). However I found it to be very slow in >> tracking, and we were getting commands timing out before the queue >> depth fell enough. >> >> It would be nice to change default queue depth in >> sas_slave_configure() to a lower value so we can avoid this patch, >> but I am not sure if other vendor's HBA performance would be >> affected. From looking at the history of sas_slave_configure(), it >> would seem the value of 256 was inherited from mpt2sas driver, so >> I'm not sure. >> > 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? Regards, John