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.
next prev parent 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