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