All of lore.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.

WARNING: multiple messages have this Message-ID (diff)
From: hch@lst.de (Christoph Hellwig)
Subject: [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@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: 24+ 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 ` 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   ` 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   ` 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   ` Christoph Hellwig
2015-04-17 20:37 ` [PATCH 4/7] block: remove REQ_TYPE_PM_SHUTDOWN Christoph Hellwig
2015-04-17 20:37   ` Christoph Hellwig
2015-04-17 20:37 ` [PATCH 5/7] block: move PM request support to IDE Christoph Hellwig
2015-04-17 20:37   ` Christoph Hellwig
2015-04-17 20:37 ` [PATCH 6/7] nbd: stop using req->cmd Christoph Hellwig
2015-04-17 20:37   ` Christoph Hellwig
2015-04-17 20:37 ` [PATCH 7/7] block: allocate block_pc data separate from struct request Christoph Hellwig
2015-04-17 20:37   ` Christoph Hellwig
2015-05-06 11:46   ` Boaz Harrosh
2015-05-06 11:46     ` Boaz Harrosh
2015-05-11  8:00     ` Christoph Hellwig [this message]
2015-05-11  8:00       ` Christoph Hellwig
2015-04-21 19:51 ` RFC: struct request cleanups Matthew Wilcox
2015-04-21 19:51   ` Matthew Wilcox
2015-05-05 19:41 ` Jens Axboe
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 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.