public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: "hch@lst.de" <hch@lst.de>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"James.Bottomley@HansenPartnership.com"
	<James.Bottomley@HansenPartnership.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"osandov@fb.com" <osandov@fb.com>,
	"hare@suse.com" <hare@suse.com>,
	"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
	"axboe@fb.com" <axboe@fb.com>
Subject: Re: [PATCH 07/18] block: Introduce request_queue.initialize_rq_fn()
Date: Mon, 22 May 2017 17:07:13 +0000	[thread overview]
Message-ID: <1495472831.2610.4.camel@sandisk.com> (raw)
In-Reply-To: <20170521063443.GF12287@lst.de>

On Sun, 2017-05-21 at 08:34 +0200, Christoph Hellwig wrote:
> On Fri, May 19, 2017 at 11:30:05AM -0700, Bart Van Assche wrote:
> > Several block drivers need to initialize the driver-private data
> > after having called blk_get_request() and before .prep_rq_fn() is
> > called, e.g. when submitting a REQ_OP_SCSI_* request. Avoid that
> > that initialization code has to be repeated after every
> > blk_get_request() call by adding a new callback function to struct
> > request_queue.
> > 
> > Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
> > Cc: Jens Axboe <axboe@fb.com>
> > Cc: Christoph Hellwig <hch@lst.de>
> > Cc: Omar Sandoval <osandov@fb.com>
> > Cc: Hannes Reinecke <hare@suse.com>
> > Cc: linux-block@vger.kernel.org
> > ---
> >  block/blk-core.c       | 3 +++
> >  block/blk-mq.c         | 3 +++
> >  include/linux/blkdev.h | 4 ++++
> >  3 files changed, 10 insertions(+)
> > 
> > diff --git a/block/blk-core.c b/block/blk-core.c
> > index a69d420b7ff0..f2540d164679 100644
> > --- a/block/blk-core.c
> > +++ b/block/blk-core.c
> > @@ -126,6 +126,9 @@ void blk_rq_init(struct request_queue *q, struct request *rq)
> >  	rq->start_time = jiffies;
> >  	set_start_time_ns(rq);
> >  	rq->part = NULL;
> > +
> > +	if (q->initialize_rq_fn)
> > +		q->initialize_rq_fn(rq);
> 
> Can we keep this out of the fast path and only do it from the
> blk_get_request / blk_mq_alloc_request path?  And while were at it
> I think those two should be merged as far as the public interface
> goes, that is we should also expose the flags argument for the
> legacy path.

Hello Christoph,

For blk-mq I could move the .initialize_rq_fn() call from
blk_mq_rq_ctx_init() into blk_mq_sched_get_request(). I can't move it
higher up in the request allocation call chain because otherwise
blk_mq_alloc_request_hctx() wouldn't call .initialize_rq_fn().

For blk-sq I'm not sure that the .initialize_rq_fn() call can be
moved because I'd like all blk_rq_init() callers to call
.initialize_rq_fn(), including ide_prep_sense().

Are you sure it would help to move the .initialize_rq_fn() calls?

Thanks,

Bart.

  reply	other threads:[~2017-05-22 17:07 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-19 18:29 [PATCH 00/18] Unify and simplify SCSI request initialization Bart Van Assche
2017-05-19 18:29 ` [PATCH 01/18] block: Introduce blk_queue_cmd_size() Bart Van Assche
2017-05-21  6:54   ` Christoph Hellwig
2017-05-19 18:30 ` [PATCH 02/18] bsg: Check private request size before attaching to a queue Bart Van Assche
2017-05-21  6:32   ` Christoph Hellwig
2017-05-21 14:33     ` Bart Van Assche
2017-05-22  7:49       ` hch
2017-05-19 18:30 ` [PATCH 03/18] pktcdvd: " Bart Van Assche
2017-05-19 18:30 ` [PATCH 04/18] cdrom: " Bart Van Assche
2017-05-19 18:30 ` [PATCH 05/18] nfsd: Check private request size before submitting a SCSI request Bart Van Assche
2017-05-19 19:03   ` J . Bruce Fields
2017-05-19 18:30 ` [PATCH 06/18] scsi: Make scsi_ioctl_reset() pass the request queue pointer to blk_rq_init() Bart Van Assche
2017-05-21  6:50   ` Christoph Hellwig
2017-05-21 16:41     ` Bart Van Assche
2017-05-22  6:06       ` Hannes Reinecke
2017-05-22  7:54         ` hch
2017-05-22  8:46           ` Hannes Reinecke
2017-05-22 12:48             ` hch
2017-05-22 12:56               ` Hannes Reinecke
2017-05-22 13:00                 ` hch
2017-05-19 18:30 ` [PATCH 07/18] block: Introduce request_queue.initialize_rq_fn() Bart Van Assche
2017-05-21  6:34   ` Christoph Hellwig
2017-05-22 17:07     ` Bart Van Assche [this message]
2017-05-19 18:30 ` [PATCH 08/18] block: Make scsi_req_init() calls implicit Bart Van Assche
2017-05-21  6:42   ` Christoph Hellwig
2017-05-19 18:30 ` [PATCH 09/18] scsi: Change argument type of scsi_req_init() Bart Van Assche
2017-05-21  6:43   ` Christoph Hellwig
2017-05-19 18:30 ` [PATCH 10/18] scsi: Only add commands to the device command list if required by the LLD Bart Van Assche
2017-05-21  6:44   ` Christoph Hellwig
2017-05-19 18:30 ` [PATCH 11/18] scsi: Move most of scsi_init_command() into scsi_initialize_rq() Bart Van Assche
2017-05-21  6:45   ` Christoph Hellwig
2017-05-21  6:46     ` Christoph Hellwig
2017-05-21  6:47   ` Christoph Hellwig
2017-05-19 18:30 ` [PATCH 12/18] scsi: Inline scsi_init_command() Bart Van Assche
2017-05-21  6:47   ` Christoph Hellwig
2017-05-19 18:30 ` [PATCH 13/18] scsi: Move sense buffer pointer initialization into scsi_initialize_rq() Bart Van Assche
2017-05-21  6:48   ` Christoph Hellwig
2017-05-19 18:30 ` [PATCH 14/18] scsi: Make scsi_initialize_rq() zero the entire struct scsi_cmnd Bart Van Assche
2017-05-21  6:49   ` Christoph Hellwig
2017-05-22 17:12     ` Bart Van Assche
2017-05-19 18:30 ` [PATCH 15/18] scsi: storvsc: Initialize driver-private command before using it Bart Van Assche
2017-05-21  6:51   ` Christoph Hellwig
2017-05-22 17:15     ` Bart Van Assche
2017-05-19 18:30 ` [PATCH 16/18] scsi-mq: Make behavior scsi_mq_prep_fn() closer to that of scsi_prep_fn() Bart Van Assche
2017-05-21  6:52   ` Christoph Hellwig
2017-05-19 18:30 ` [PATCH 17/18] scsi: Consolidate more initialization code Bart Van Assche
2017-05-21  6:52   ` Christoph Hellwig
2017-05-19 18:30 ` [PATCH 18/18] scsi_setup_fs_cmnd(): Call scsi_req_init() instead of open-coding it Bart Van Assche
2017-05-21  6:52   ` Christoph Hellwig

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=1495472831.2610.4.camel@sandisk.com \
    --to=bart.vanassche@sandisk.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=axboe@fb.com \
    --cc=hare@suse.com \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=osandov@fb.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox