All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-scsi@vger.kernel.org,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	Robert Elliott <elliott@hp.com>, Hannes Reinecke <hare@suse.de>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Bart van Assche <bvanassche@acm.org>,
	Mike Christie <michaelc@cs.wisc.edu>
Subject: making the queue_type attribute read only, was: Re: tag handling refactor V2
Date: Wed, 12 Nov 2014 09:41:42 -0800	[thread overview]
Message-ID: <20141112174142.GA14359@infradead.org> (raw)
In-Reply-To: <1415634990-3023-1-git-send-email-hch@lst.de>

>  - how is the change_queue_type API supposed to be used for most drivers?  It
>    only changes the tag type from none to simple or back, but except for the
>    special implementation in the 53c700 driver doesn't change the queue depth,
>    which might cause it to issue multiple non-tagged command.  Fortunately
>    most drivers never look at this information, but then again changing the
>    queue type is useless to start with.
>  - for those drivers looking at the command tagged information we'd need
>    to quiesce the LUN.  No driver but the 53c700 driver does that, and the
>    53c700 does it at a target-level, which despite a comment claiming it's
>    needed doesn't seem to make sense given the code.  If we can make sure
>    to quience all LUNs we could avoid the per-command flag for tagged commands
>    and always look at the scsi_device flag.

I've not merged the series, but ondering the above two issues I've
become convinved that we should make the queue_type sysfs attribute read
only.

Switching off tagging isn't really something we should leave to users,
as the hardware knows much better.  Changing the tag type might have
made sense during the times of the ordered tags for barriers insanity,
but now that it's just tagged vs untagged it's pretty pointless.
Especially given that only a single driver ever got the implementation
right.

Does anyone have objections to removing the change_queue_type method?


  parent reply	other threads:[~2014-11-12 17:41 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-10 15:56 tag handling refactor V2 Christoph Hellwig
2014-11-10 15:56 ` [PATCH 01/11] scsi: provide a generic change_queue_type method Christoph Hellwig
2014-11-10 15:56 ` [PATCH 02/11] scsi: add new scsi-command flag for tagged commands Christoph Hellwig
2014-11-10 15:56 ` [PATCH 03/11] scsi: remove ordered_tags scsi_device field Christoph Hellwig
2014-11-11 15:37   ` Hannes Reinecke
2014-11-10 15:56 ` [PATCH 04/11] scsi: remove ordered_tag host template field Christoph Hellwig
2014-11-10 15:56 ` [PATCH 05/11] scsi: remove abuses of scsi_populate_tag Christoph Hellwig
2014-11-11 15:39   ` Hannes Reinecke
2014-11-10 15:56 ` [PATCH 06/11] mptfusion: don't change queue type in ->change_queue_depth Christoph Hellwig
2014-11-10 15:56 ` [PATCH 07/11] scsi: remove use_blk_tcq Scsi_Host field Christoph Hellwig
2014-11-10 15:56 ` [PATCH 08/11] scsi: always assign block layer tags if enabled Christoph Hellwig
2014-11-10 15:56 ` [PATCH 09/11] scsi: don't set tagging state from scsi_adjust_queue_depth Christoph Hellwig
2014-11-11 15:41   ` Hannes Reinecke
2014-11-10 15:56 ` [PATCH 10/11] scsi: don't force tagged_supported in drivers Christoph Hellwig
2014-11-11 15:42   ` Hannes Reinecke
2014-11-10 15:56 ` [PATCH 11/11] ufs: remove spurious scsi_set_tag_type call Christoph Hellwig
2014-11-11 15:42   ` Hannes Reinecke
2014-11-10 18:06 ` tag handling refactor V2 Mike Christie
2014-11-10 22:28 ` Jens Axboe
2014-11-12 17:41 ` Christoph Hellwig [this message]
2014-11-13  0:33   ` making the queue_type attribute read only, was: " Elliott, Robert (Server Storage)
2014-11-13 11:28     ` Christoph Hellwig
2014-11-13  1:15 ` James Bottomley

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=20141112174142.GA14359@infradead.org \
    --to=hch@infradead.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=bvanassche@acm.org \
    --cc=elliott@hp.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=michaelc@cs.wisc.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.