linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladislav Bolkhovitin <vst@vlnb.net>
To: Boaz Harrosh <bharrosh@panasas.com>
Cc: Tejun Heo <tj@kernel.org>,
	linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	scst-devel@lists.sourceforge.net,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	Jens Axboe <jens.axboe@oracle.com>,
	Joe Eykholt <jeykholt@cisco.com>
Subject: Re: [PATCH v2]: New implementation of scsi_execute_async()
Date: Thu, 16 Jul 2009 22:15:00 +0400	[thread overview]
Message-ID: <4A5F6E24.3080800@vlnb.net> (raw)
In-Reply-To: <4A5D9C46.2000002@panasas.com>

Boaz Harrosh, on 07/15/2009 01:07 PM wrote:
> On 07/14/2009 07:17 PM, Vladislav Bolkhovitin wrote:
>> This patch reimplements scsi_execute_async(). In the new version it's a lot less
>> hackish and also has additional features. Namely:
>>
>> 1. Possibility to insert commands both in tail and in head of the queue.
>>
>> 2. Possibility to explicitly specify if the last SG element has space for padding.
>>
>> This patch based on the previous patches posted by Tejun Heo. Comparing to them
>> it has the following improvements:
>>
>> 1. It uses BIOs chaining instead of kmalloc()ing the whole bio.
>>
>> 2. It uses SGs chaining instead of kmalloc()ing one big SG in case if direct
>> mapping failed (e.g. because of DMA alignment or padding).
>>
>> 3. If direct mapping failed, if possible, it copies only the last SG element,
>> not the whole SG.
>>
>> 4. When needed, copy_page() is used instead of memcpy() to copy the whole pages.
>>
>> Also this patch adds and exports functions sg_copy() and sg_copy_elem(), which
>> cop one SG to another and one SG element to another respectively.
>>
>> At the moment SCST is the only user of this functionality. It needs it, because
>> its target drivers, which are, basically, SCSI drivers, can deal only with SGs,
>> not with BIOs. But, according the latest discussions, there are other potential
>> users for of this functionality, so I'm sending this patch in a hope that it will be
>> also useful for them and eventually will be merged in the mainline kernel.
>>
>> This patch requires previously sent patch with subject "[PATCH]: Rename REQ_COPY_USER
>> to more descriptive REQ_HAS_TAIL_SPACE_FOR_PADDING".
>>
>> It's against 2.6.30.1, but if necessary, I can update it to any necessary
>> kernel version.
>>
>> Signed-off-by: Vladislav Bolkhovitin <vst@vlnb.net>
>>
>>  block/blk-map.c             |  408 ++++++++++++++++++++++++++++++++++++++++++++
>>  drivers/scsi/scsi_lib.c     |  108 +++++++++++
>>  include/linux/blkdev.h      |    3 
>>  include/linux/scatterlist.h |    7 
>>  include/scsi/scsi_device.h  |   11 +
>>  lib/scatterlist.c           |  147 +++++++++++++++
>>  6 files changed, 683 insertions(+), 1 deletion(-)
>>
>> diff -upkr linux-2.6.30.1/block/blk-map.c linux-2.6.30.1/block/blk-map.c
>> --- linux-2.6.30.1/block/blk-map.c	2009-07-10 21:13:25.000000000 +0400
>> +++ linux-2.6.30.1/block/blk-map.c	2009-07-14 19:24:36.000000000 +0400
>> @@ -5,6 +5,7 @@
>>  #include <linux/module.h>
>>  #include <linux/bio.h>
>>  #include <linux/blkdev.h>
>> +#include <linux/scatterlist.h>
>>  #include <scsi/sg.h>		/* for struct sg_iovec */
>>  
>>  #include "blk.h"
>> @@ -272,6 +273,413 @@ int blk_rq_unmap_user(struct bio *bio)
>>  }
>>  EXPORT_SYMBOL(blk_rq_unmap_user);
>>  
>> +struct blk_kern_sg_hdr {
>> +	struct scatterlist *orig_sgp;
>> +	union {
>> +		struct sg_table new_sg_table;
>> +		struct scatterlist *saved_sg;
>> +	};
> 
> There is a struct scatterlist * inside struct sg_table
> just use that. No need for a union. (It's not like your saving
> space). In the tail case nents == 1.
> (orig_nents==0 and loose the tail_only)

This will uncover internal details of SG-chaining implementation, which 
you wanted to hide. Or didn't?

>> +	while (hbio != NULL) {
>> +		bio = hbio;
>> +		hbio = hbio->bi_next;
>> +		bio->bi_next = NULL;
>> +
>> +		blk_queue_bounce(q, &bio);
> 
> I do not understand. If you are bouncing on the bio level.
> why do you need to do all the alignment checks and
> sg-bouncing + tail handling all this is done again on the bio
> level.

blk_queue_bounce() does another and completely independent level of 
bouncing for pages allocated in the not accessible by the device area.

> It looks to me that perhaps you did not understand Tejun's code
> His code, as I remember, was on the bio level, but here you
> are duplicating what is done in bio level.
> 
> But maybe I don't understand. Tejun?
>
>> +	req->cmd_len = cmd_len;
>> +	memset(req->cmd, 0, BLK_MAX_CDB); /* ATAPI hates garbage after CDB */
>> +	memcpy(req->cmd, cmd, req->cmd_len);
> 
> Does not support large commands.

Will be fixed.

(BTW, the SCSI layer assumes large CDBs as single big buffers, but all 
SCSI transports I checked transfer large CDBs in 2 different parts: the 
first 16 bytes and the rest. I.e. they deal with 2 different buffers. 
So, the target side (SCST) deals with 2 buffers for large CDBs as well. 
Having only one req->cmd will force SCST to merge those 2 buffers into a 
single buffer. So, scs[i,t]_execute_async() will have to make an 
allocation for this as well.)

>> +/**
>> + * sg_copy_elem - copy one SG element to another
>> + * @dst_sg:	destination SG element
>> + * @src_sg:	source SG element
>> + * @copy_len:	maximum amount of data to copy. If 0, then copy all.
>> + * @d_km_type:	kmap_atomic type for the destination SG
>> + * @s_km_type:	kmap_atomic type for the source SG
>> + *
>> + * Description:
>> + *    Data from the source SG element will be copied to the destination SG
>> + *    element. Returns number of bytes copied. Can switch to the next dst_sg
>> + *    element, so, to copy to strictly only one dst_sg element, it must be
>> + *    either last in the chain, or copy_len == dst_sg->length.
>> + */
>> +int sg_copy_elem(struct scatterlist *dst_sg, struct scatterlist *src_sg,
>> +		 size_t copy_len, enum km_type d_km_type,
>> +		 enum km_type s_km_type)
>> +{
>> +	size_t dst_len = dst_sg->length, dst_offs = dst_sg->offset;
>> +
>> +	return __sg_copy_elem(&dst_sg, &dst_len, &dst_offs, src_sg,
>> +		copy_len, d_km_type, s_km_type);
>> +}
>> +EXPORT_SYMBOL(sg_copy_elem);
> 
> Is not sg_copy_elem a copy of an sg with one element. Why do we need
> two exports.

Perhaps, yes.

> I would pass a nents count to below and discard this one.

Perhaps, yes, but only for possible future use. I don't see any use of 
it at the moment.

>> +
>> +/**
>> + * sg_copy - copy one SG vector to another
>> + * @dst_sg:	destination SG
>> + * @src_sg:	source SG
>> + * @copy_len:	maximum amount of data to copy. If 0, then copy all.
>> + * @d_km_type:	kmap_atomic type for the destination SG
>> + * @s_km_type:	kmap_atomic type for the source SG
>> + *
>> + * Description:
>> + *    Data from the source SG vector will be copied to the destination SG
>> + *    vector. End of the vectors will be determined by sg_next() returning
>> + *    NULL. Returns number of bytes copied.
>> + */
>> +int sg_copy(struct scatterlist *dst_sg,
>> +	    struct scatterlist *src_sg, size_t copy_len,
> 
> Total length is nice, but also a nents count
> 
>> +	    enum km_type d_km_type, enum km_type s_km_type)
>> +{
>> +	int res = 0;
>> +	size_t dst_len, dst_offs;
>> +
>> +	if (copy_len == 0)
>> +		copy_len = 0x7FFFFFFF; /* copy all */
>> +
>> +	dst_len = dst_sg->length;
>> +	dst_offs = dst_sg->offset;
>> +
>> +	do {
>> +		copy_len -= __sg_copy_elem(&dst_sg, &dst_len, &dst_offs,
>> +				src_sg, copy_len, d_km_type, s_km_type);
>> +		if ((copy_len == 0) || (dst_sg == NULL))
>> +			goto out;
>> +
>> +		src_sg = sg_next(src_sg);
>> +	} while (src_sg != NULL);
>> +
>> +out:
>> +	return res;
>> +}
>> +EXPORT_SYMBOL(sg_copy);

Thanks,
Vlad


  parent reply	other threads:[~2009-07-16 18:14 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-09 18:14 [PATCH]: New implementation of scsi_execute_async() Vladislav Bolkhovitin
2009-07-09 19:35 ` Joe Eykholt
2009-07-10 10:59   ` Joe Eykholt
2009-07-14 16:16     ` Vladislav Bolkhovitin
2009-07-12 13:03 ` Boaz Harrosh
2009-07-14 16:16   ` Vladislav Bolkhovitin
2009-07-15  8:19     ` Boaz Harrosh
2009-07-16 18:13       ` Vladislav Bolkhovitin
2009-07-19 11:34         ` Boaz Harrosh
2009-07-20 17:54           ` Vladislav Bolkhovitin
2009-07-21  8:03             ` Boaz Harrosh
2009-07-21 18:26               ` Vladislav Bolkhovitin
2009-07-14 16:17 ` [PATCH v2]: " Vladislav Bolkhovitin
2009-07-14 18:24   ` Vladislav Bolkhovitin
2009-07-15  9:07   ` Boaz Harrosh
2009-07-15 17:48     ` Joe Eykholt
2009-07-16 18:15       ` Vladislav Bolkhovitin
2009-07-16  7:54     ` Tejun Heo
2009-07-16 18:15     ` Vladislav Bolkhovitin [this message]
2009-07-19 11:35       ` Boaz Harrosh
2009-07-20 17:56         ` Vladislav Bolkhovitin
2009-07-16  7:52   ` Tejun Heo
2009-07-16 18:17     ` Vladislav Bolkhovitin
2009-08-12 17:47 ` [PATCH]: Implementation of blk_rq_map_kern_sg() (aka New implementation of scsi_execute_async() v3) Vladislav Bolkhovitin
2009-08-15  8:22   ` Jens Axboe
2009-09-03 16:34     ` Vladislav Bolkhovitin

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=4A5F6E24.3080800@vlnb.net \
    --to=vst@vlnb.net \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=bharrosh@panasas.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=jens.axboe@oracle.com \
    --cc=jeykholt@cisco.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=scst-devel@lists.sourceforge.net \
    --cc=tj@kernel.org \
    /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).