RE: [PATCH v2 10/12] IB/srp: Use block layer tags

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@xxxxxxxxxxxxx]
> Sent: Thursday, October 23, 2014 3:48 AM
> To: Elliott, Robert (Server Storage)
> Cc: Bart Van Assche; Jens Axboe; Sagi Grimberg; Sebastian Parschauer;
> Ming Lei; linux-scsi@xxxxxxxxxxxxxxx; linux-rdma; Scales, Webb; Don
> Brace (PMC)
> Subject: Re: [PATCH v2 10/12] IB/srp: Use block layer tags
> 
> On Wed, Oct 22, 2014 at 10:03:24PM +0000, Elliott, Robert (Server
> Storage) wrote:
> > Have you tested this with scsi_mod.use_blk_mq=n?
> >
> > Trying similar changes in hpsa, we still receive some INQUIRY commands
> > submitted through queuecommand with tag -1.  They are for devices for
> > which slave_alloc has not yet been run, implying this work needs to
> > be done even earlier.  Maybe the midlayer is missing a slave_alloc
> > call somewhere?
> 
> Did that version of hpsa really enable tagging in slave_alloc
> or just in slave_configure?  The latter would cause INQUIRY to be
> sent untagged.

Yes, it is slave_alloc, not slave_configure.  

However, it was looking at scmd->tag, which is always 0xff (at 
least in those early discovery commands).  scmd->request->tag 
looks like it is the field that has the correct values.

Also, I noticed that scmd->tag is just an 8 bit field, so
it could never represent a large number of tags.

Just to confirm: After calling scsi_init_shared_tag_map()
in non-mq mode, will scmd->request->tag be based on 
controller-wide tag allocation (never using the same
value at the same time for the request queues of multiple
devices in that controller)?


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux