All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	Chris Wright <chrisw@sous-sol.org>, Jens Axboe <axboe@kernel.dk>,
	Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
	<kvm@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/5] block: add bio_map_sg
Date: Thu, 6 Oct 2011 00:51:39 +0200	[thread overview]
Message-ID: <4E8CDF7B.7000601@panasas.com> (raw)
In-Reply-To: <20111005195529.760114992@bombadil.infradead.org>

On 10/05/2011 09:54 PM, Christoph Hellwig wrote:
> Add a helper to map a bio to a scatterlist, modelled after blk_rq_map_sg.
> This helper is useful for any driver that wants to create a scatterlist
> from its ->make_request method.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> 

I have some questions.

- Could we later use this bio_map_sg() to implement blk_rq_map_sg() and
  remove some duplicated code?

- Don't you need to support a chained bio (bio->next != NULL)? Because
  I did not see any looping in the last patch 
	[PATCH 5/5] virtio-blk: implement ->make_request
  Or is it that ->make_request() is a single bio at a time?
  If so could we benefit from both bio-chaining and sg-chaning to
  make bigger IOs?

Thanks
Boaz

> Index: linux-2.6/block/blk-merge.c
> ===================================================================
> --- linux-2.6.orig/block/blk-merge.c	2011-10-04 11:49:32.857014742 -0400
> +++ linux-2.6/block/blk-merge.c	2011-10-04 13:37:51.305630951 -0400
> @@ -199,6 +199,69 @@ new_segment:
>  }
>  EXPORT_SYMBOL(blk_rq_map_sg);
>  
> +/*
> + * map a bio to a scatterlist, return number of sg entries setup. Caller
> + * must make sure sg can hold bio->bi_phys_segments entries
> + */
> +int bio_map_sg(struct request_queue *q, struct bio *bio,
> +		  struct scatterlist *sglist)
> +{
> +	struct bio_vec *bvec, *bvprv;
> +	struct scatterlist *sg;
> +	int nsegs, cluster;
> +	unsigned long i;
> +
> +	nsegs = 0;
> +	cluster = blk_queue_cluster(q);
> +
> +	bvprv = NULL;
> +	sg = NULL;
> +	bio_for_each_segment(bvec, bio, i) {
> +		int nbytes = bvec->bv_len;
> +
> +		if (bvprv && cluster) {
> +			if (sg->length + nbytes > queue_max_segment_size(q))
> +				goto new_segment;
> +
> +			if (!BIOVEC_PHYS_MERGEABLE(bvprv, bvec))
> +				goto new_segment;
> +			if (!BIOVEC_SEG_BOUNDARY(q, bvprv, bvec))
> +				goto new_segment;
> +
> +			sg->length += nbytes;
> +		} else {
> +new_segment:
> +			if (!sg)
> +				sg = sglist;
> +			else {
> +				/*
> +				 * If the driver previously mapped a shorter
> +				 * list, we could see a termination bit
> +				 * prematurely unless it fully inits the sg
> +				 * table on each mapping. We KNOW that there
> +				 * must be more entries here or the driver
> +				 * would be buggy, so force clear the
> +				 * termination bit to avoid doing a full
> +				 * sg_init_table() in drivers for each command.
> +				 */
> +				sg->page_link &= ~0x02;
> +				sg = sg_next(sg);
> +			}
> +
> +			sg_set_page(sg, bvec->bv_page, nbytes, bvec->bv_offset);
> +			nsegs++;
> +		}
> +		bvprv = bvec;
> +	} /* segments in bio */
> +
> +	if (sg)
> +		sg_mark_end(sg);
> +
> +	BUG_ON(bio->bi_phys_segments && nsegs > bio->bi_phys_segments);
> +	return nsegs;
> +}
> +EXPORT_SYMBOL(bio_map_sg);
> +
>  static inline int ll_new_hw_segment(struct request_queue *q,
>  				    struct request *req,
>  				    struct bio *bio)
> Index: linux-2.6/include/linux/blkdev.h
> ===================================================================
> --- linux-2.6.orig/include/linux/blkdev.h	2011-10-04 13:37:13.216148915 -0400
> +++ linux-2.6/include/linux/blkdev.h	2011-10-04 13:37:51.317613617 -0400
> @@ -854,6 +854,8 @@ extern void blk_queue_flush_queueable(st
>  extern struct backing_dev_info *blk_get_backing_dev_info(struct block_device *bdev);
>  
>  extern int blk_rq_map_sg(struct request_queue *, struct request *, struct scatterlist *);
> +extern int bio_map_sg(struct request_queue *q, struct bio *bio,
> +		struct scatterlist *sglist);
>  extern void blk_dump_rq_flags(struct request *, char *);
>  extern long nr_blockdev_pages(void);
>  
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


  reply	other threads:[~2011-10-05 22:52 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-05 19:54 [PATCH 0/5] RFC: ->make_request support for virtio-blk Christoph Hellwig
2011-10-05 19:54 ` [PATCH 1/5] block: add bio_map_sg Christoph Hellwig
2011-10-05 22:51   ` Boaz Harrosh [this message]
2011-10-06 13:40     ` Christoph Hellwig
2011-10-05 19:54 ` [PATCH 2/5] virtio: support unlocked queue kick Christoph Hellwig
2011-10-06  8:42   ` Stefan Hajnoczi
     [not found]   ` <87r52qgaf3.fsf@rustcorp.com.au>
2011-10-06 13:19     ` Michael S. Tsirkin
2011-11-01 14:40       ` Michael S. Tsirkin
2011-11-02  3:19         ` Rusty Russell
2011-11-02  7:25           ` Christoph Hellwig
2011-11-03  4:01             ` Rusty Russell
2011-11-03  5:15               ` Rusty Russell
2011-11-03  6:45   ` Minchan Kim
2011-10-05 19:54 ` [PATCH 3/5] virtio-blk: remove the unused list of pending requests Christoph Hellwig
2011-10-05 19:54 ` [PATCH 4/5] virtio-blk: reimplement the serial attribute without using requests Christoph Hellwig
2011-10-05 19:54 ` [PATCH 5/5] virtio-blk: implement ->make_request Christoph Hellwig
2011-10-06  1:52   ` Rusty Russell
2011-10-06 13:42     ` Christoph Hellwig
2011-10-06 13:53   ` Jens Axboe
2011-10-05 20:31 ` [PATCH 0/5] RFC: ->make_request support for virtio-blk Vivek Goyal
2011-10-05 21:53   ` Christoph Hellwig

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=4E8CDF7B.7000601@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=axboe@kernel.dk \
    --cc=chrisw@sous-sol.org \
    --cc=hch@infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=stefanha@linux.vnet.ibm.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.