On Tue, 2013-12-03 at 11:46 -0600, Alireza Haghdoost wrote: > On Tue, Dec 3, 2013 at 7:25 AM, James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > Well, no, we could have used Ordered instead of Simple tags ... that > > would preserve submission order according to spec. This wouldn't really > > work for SATA because NCQ only has simple tags. > > Thanks a lot James for your comments. Is it possible to configure TCQ > mode to the Ordered tag instead of Simple tags? I understand that NCQ > does not support Ordered tags but I think it would be nice to keep > this functionality as an option for other SCSI targets like qla2xxx. > I can see the discussion about TAG ordering in the mailing list. > However, I am not sure if it is functional right now or not. It's set in the scsi_populate_tag() inline function (scsi_tcq.h). That's currently hard coded to simple tags. > > The point is that our > > granular unit of ordering is between two barriers, which is way above > > the request/tag level so we didn't bother to enforce tag ordering. > > Does a barrier force flush all in_flight SCSI commands ? A flush barrier does, yes ... that's the predominant implementation. > Based on my > understanding if we put a barrier between multiple requests, it wont > return until TCQ process all in_flight scsi commands. Which means we > can not keep a fixed load on TCQ and it would certainly reduce the > throughput of our application. Yes, that's what we see in filesystems with barriers enabled. It's the price we pay for integrity. > > However, handling > > strict ordering in the face of requeuing events like QUEUE FULL or BUSY > > is hard so we didn't bother. > > We have a peace of code to monitor in_flight requests and avoid > QUEUE_FULL events. However, would you please let us know a case that > cause a BUSY events ? Does it means the scsi target is busy processing > other requests with-in the same host machine ? BUSY is a catch all status. It's different from QUEUE FULL because queue tracking algorithms use QUEUE FULL to determine the optimal number of in-flight commands (we can do that in the mid-layer today with the queue full tracking code). BUSY means the command needs retrying because of some other condition on the initiator that isn't connected with the task queues, so it isn't counted against the queue full status tracking for reducing command flows. It's most often returned by multi-initiator devices in the presence of management (or even statistics type) conditions, or because of scheduling or caching issues. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
