From: Boaz Harrosh <bharrosh@panasas.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: James.Bottomley@SteelEye.com, jens.axboe@oracle.com,
linux-scsi@vger.kernel.org, bhalevy@panasas.com,
hch@infradead.org, akpm@linux-foundation.org,
michaelc@cs.wisc.edu
Subject: Re: [PATCH v2] add bidi support for block pc requests
Date: Thu, 10 May 2007 15:37:48 +0300 [thread overview]
Message-ID: <4643121C.600@panasas.com> (raw)
In-Reply-To: <20070510164535F.fujita.tomonori@lab.ntt.co.jp>
FUJITA Tomonori wrote:
> From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> Subject: Re: [PATCH v2] add bidi support for block pc requests
> Date: Thu, 10 May 2007 15:53:22 +0900
>
>> From: Boaz Harrosh <bharrosh@panasas.com>
>> Subject: Re: [PATCH v2] add bidi support for block pc requests
>> Date: Wed, 09 May 2007 19:54:32 +0300
>>
>>> James Bottomley wrote:
>>>> Actually, the first order of business is to use accessors on the command
>>>> pointers in the drivers to free them from the internal layout of the
>>>> structure (and where it is allocated).
>>>>
>>> Thanks! I totally second that. Let me look into my old patches and come
>>> up with all the needed accessors. I hope 3-5 will be enough.
>>> I will send some suggestions tomorrow.
>>>> No, that's why you do the accessors. Convert all of the common drivers
>>>> to accessors on the current structure, then throw the switch to convert
>>>> to the new structure (whatever form is finally settled on). Then any
>>>> unconverted drivers break and people fix the ones they care about.
>>> Last time I was able to compile 97% of drivers and convert by search-and-replace
>>> the rest. Not a huge deal.
>> We need to remove the non-use-sg code in the drivers and convert
>> them. So it's a bit more complicated than search-and-replace.
>
> Here's a patch to convert ibmvscsi to use helper functions (though it
> needs more testings).
>
> ---
> ---
> diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
> index d6948d0..799f204 100644
> --- a/include/scsi/scsi_cmnd.h
> +++ b/include/scsi/scsi_cmnd.h
> @@ -138,4 +138,17 @@ extern void scsi_kunmap_atomic_sg(void *
> extern struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd *, gfp_t);
> extern void scsi_free_sgtable(struct scatterlist *, int);
>
> +extern int scsi_dma_map(struct device *dev, struct scsi_cmnd *cmd);
> +extern void scsi_dma_unmap(struct device *dev, struct scsi_cmnd *cmd);
> +
> +/* moved to scatterlist.h after chaining sg */
> +#define sg_next(sg) ((sg) + 1)
> +
> +#define scsi_for_each_sg(cmd, nseg, i) \
> + for (i = 0, sg = (cmd)->request_buffer; i < nseg; \
> + sg = sg_next(sg), i++) \
> +
Better we do like Jens's patch
+#define for_each_sg(sglist, sg, nr, __i) \
+ for (__i = 0, sg = (sglist); __i < (nr); __i++, sg = sg_next(sg))
I think that we should wait for Jens pending patchset and do this work on top
of his, then use his sg macros directly. This way the cleaners can also be
watchfully for any drivers that might brake with big IO sent to them.
> +#define scsi_sg_count(cmd) ((cmd)->use_sg)
> +#define scsi_bufferlen(cmd) ((cmd)->request_bufflen)
> +
> #endif /* _SCSI_SCSI_CMND_H */
Above helpers look good. However I am missing 2 of them:
1.
+#define scsi_sgl(cmd) ((struct scatterlist*)(cmd)->request_buffer)
This is for drivers like iSCSI that do not do any dma mapping, as dma
is done at the lower level in the NICs. And lots of other places that just
transfer the sglist around.
2.
+#define scsi_resid(cmd) ((cmd)->resid)
Boaz
next prev parent reply other threads:[~2007-05-10 12:39 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-08 2:25 [PATCH v2] add bidi support for block pc requests FUJITA Tomonori
2007-05-08 18:53 ` Boaz Harrosh
2007-05-08 20:01 ` James Bottomley
2007-05-09 7:46 ` Boaz Harrosh
2007-05-09 10:52 ` FUJITA Tomonori
2007-05-09 13:58 ` Boaz Harrosh
2007-05-09 14:54 ` FUJITA Tomonori
2007-05-09 14:55 ` James Bottomley
2007-05-09 16:54 ` Boaz Harrosh
2007-05-10 6:53 ` FUJITA Tomonori
2007-05-10 7:45 ` FUJITA Tomonori
2007-05-10 12:37 ` Boaz Harrosh [this message]
2007-05-10 13:01 ` FUJITA Tomonori
2007-05-10 15:10 ` Douglas Gilbert
2007-05-10 15:48 ` Boaz Harrosh
2007-05-11 16:26 ` James Bottomley
2007-05-16 17:29 ` Boaz Harrosh
2007-05-16 17:53 ` Jens Axboe
2007-05-16 18:06 ` James Bottomley
2007-05-16 18:13 ` Jens Axboe
2007-05-17 8:46 ` Boaz Harrosh
2007-05-17 2:57 ` FUJITA Tomonori
2007-05-17 5:48 ` Jens Axboe
2007-05-17 5:59 ` FUJITA Tomonori
2007-05-17 8:49 ` Boaz Harrosh
2007-05-17 11:12 ` FUJITA Tomonori
2007-05-17 17:37 ` Benny Halevy
2007-05-24 16:37 ` Boaz Harrosh
2007-05-24 16:46 ` Boaz Harrosh
2007-05-24 16:47 ` FUJITA Tomonori
2007-05-24 16:59 ` Boaz Harrosh
2007-05-17 11:29 ` FUJITA Tomonori
2007-05-17 13:27 ` James Bottomley
2007-05-17 14:00 ` Boaz Harrosh
2007-05-17 14:11 ` FUJITA Tomonori
2007-05-17 15:49 ` Boaz Harrosh
2007-06-01 20:21 ` Jeff Garzik
2007-06-03 7:45 ` Boaz Harrosh
2007-06-03 13:17 ` James Bottomley
2007-07-07 15:27 ` Jeff Garzik
2007-07-07 15:42 ` James Bottomley
2007-07-07 16:59 ` Jeff Garzik
2007-05-09 10:49 ` FUJITA Tomonori
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=4643121C.600@panasas.com \
--to=bharrosh@panasas.com \
--cc=James.Bottomley@SteelEye.com \
--cc=akpm@linux-foundation.org \
--cc=bhalevy@panasas.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=hch@infradead.org \
--cc=jens.axboe@oracle.com \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
/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;
as well as URLs for NNTP newsgroup(s).