From: Christoph Hellwig <hch@infradead.org>
To: Boaz Harrosh <bharrosh@panasas.com>
Cc: Christoph Hellwig <hch@infradead.org>,
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 09:40:21 -0400 [thread overview]
Message-ID: <20111006134021.GA20190@infradead.org> (raw)
In-Reply-To: <4E8CDF7B.7000601@panasas.com>
On Thu, Oct 06, 2011 at 12:51:39AM +0200, Boaz Harrosh wrote:
> I have some questions.
>
> - Could we later use this bio_map_sg() to implement blk_rq_map_sg() and
> remove some duplicated code?
I didn't even think about that, but it actually looks very possible
to factor the "meat" in the for each bvec loop into a common helper
used by both.
> - 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?
At this point ->make_request is a single bio interface. I have some
WIP patches to do the onstack plugging per bio, at which point it would
change to take a list. For this to work we'd need major changes to
all ->make_request drivers.
next prev parent reply other threads:[~2011-10-06 13:40 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
2011-10-06 13:40 ` Christoph Hellwig [this message]
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=20111006134021.GA20190@infradead.org \
--to=hch@infradead.org \
--cc=axboe@kernel.dk \
--cc=bharrosh@panasas.com \
--cc=chrisw@sous-sol.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.