public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Boaz Harrosh <ooo@electrozaur.com>
Cc: axboe@kernel.dk, linux-nvme@lists.infradead.org,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH 7/7] block: allocate block_pc data separate from struct request
Date: Mon, 11 May 2015 10:00:55 +0200	[thread overview]
Message-ID: <20150511080054.GA32417@lst.de> (raw)
In-Reply-To: <5549FF0A.6010901@electrozaur.com>

On Wed, May 06, 2015 at 02:46:18PM +0300, Boaz Harrosh wrote:
> > -	memset(rq->__cmd, 0, sizeof(rq->__cmd));
> > +
> > +	rq->block_pc = kzalloc(sizeof(*rq->block_pc) + cmd_len, gfp);
> 
> I wish you would not embed a dynamic allocation here for any
> driver regardless. This extra allocation does hurt a lot. See how in
> SCSI fs commands you embedded it in scsi_cmnd so it catches as well
> for multi-Q pre-allocation.
> 
> I think you need to just make it the same as *sense pass it from outside
> and the allocation is the caller responsibility. The caller must have
> an end-request call back set. (Or is a sync call)
> 
> Usually all users already have a structure to put this in. The only bit
> more work is to take care of the free. If they are already passing sense
> then they already need to free at end of request. Those that are synchronous
> can have it on the stack. Only very few places need a bit of extra work.

Actually most don't have a structure ready, that's why I ressorted to this
version.  But once this is in you can easily add low-level version that
allows passing a preallocate cdb buffer for the OSD case.

> > +struct block_pc_request {
> > +	unsigned short cmd_len;
> > +	unsigned int sense_len;
> > +	void *sense;
> 
> Better move cmd_len here the short will combine well
> with the char array.

Thanks.

> > +	union {
> > +		struct block_pc_request *block_pc;
> > +		void *drv_private;
> > +	};
> > +
> 
> Exactly. drv_private is allocated by caller we can do the same for
> block_pc. Also If (theoretically) a driver needs both it is just the
> same pointer right? (container_of)

I probably need to rename the field.  It's only driver private when
the low-level driver itself submits the request, e.g. internal commands
in the LLDD.  But in that particular case what you suggest is fine.

  reply	other threads:[~2015-05-11  8:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-17 20:37 RFC: struct request cleanups Christoph Hellwig
2015-04-17 20:37 ` [PATCH 1/7] block: rename REQ_TYPE_SPECIAL to REQ_TYPE_DRV_PRIV Christoph Hellwig
2015-04-17 20:37 ` [PATCH 2/7] block: move REQ_TYPE_ATA_TASKFILE and REQ_TYPE_ATA_PC to ide.h Christoph Hellwig
2015-04-17 20:37 ` [PATCH 3/7] block: move REQ_TYPE_SENSE to the ide driver Christoph Hellwig
2015-04-17 20:37 ` [PATCH 4/7] block: remove REQ_TYPE_PM_SHUTDOWN Christoph Hellwig
2015-04-17 20:37 ` [PATCH 5/7] block: move PM request support to IDE Christoph Hellwig
2015-04-17 20:37 ` [PATCH 6/7] nbd: stop using req->cmd Christoph Hellwig
2015-04-17 20:37 ` [PATCH 7/7] block: allocate block_pc data separate from struct request Christoph Hellwig
2015-05-06 11:46   ` Boaz Harrosh
2015-05-11  8:00     ` Christoph Hellwig [this message]
2015-04-21 19:51 ` RFC: struct request cleanups Matthew Wilcox
2015-05-05 19:41 ` Jens Axboe

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=20150511080054.GA32417@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=ooo@electrozaur.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