Re: [dm-devel] [PATCH V10 09/19] block: introduce bio_bvecs()

2018-11-21 Thread Ming Lei
On Tue, Nov 20, 2018 at 09:35:07PM -0800, Sagi Grimberg wrote: > > > > Wait, I see that the bvec is still a single array per bio. When you said > > > a table I thought you meant a 2-dimentional array... > > > > I mean a new 1-d table A has to be created for multiple bios in one rq, > > and build

Re: [dm-devel] [PATCH V10 09/19] block: introduce bio_bvecs()

2018-11-21 Thread Christoph Hellwig
On Tue, Nov 20, 2018 at 09:35:07PM -0800, Sagi Grimberg wrote: >> Given it is over TCP, I guess it should be doable for you to preallocate one >> 256-bvec table in one page for each request, then sets the max segment size >> as >> (unsigned int)-1, and max segment number as 256, the preallocated

Re: [dm-devel] [PATCH V10 09/19] block: introduce bio_bvecs()

2018-11-20 Thread Sagi Grimberg
Wait, I see that the bvec is still a single array per bio. When you said a table I thought you meant a 2-dimentional array... I mean a new 1-d table A has to be created for multiple bios in one rq, and build it in the following way rq_for_each_bvec(tmp, rq, rq_iter)

Re: [dm-devel] [PATCH V10 09/19] block: introduce bio_bvecs()

2018-11-20 Thread Ming Lei
On Tue, Nov 20, 2018 at 08:42:04PM -0800, Sagi Grimberg wrote: > > > > Yeah, that is the most common example, given merge is enabled > > > in most of cases. If the driver or device doesn't care merge, > > > you can disable it and always get single bio request, then the > > > bio's bvec table can

Re: [dm-devel] [PATCH V10 09/19] block: introduce bio_bvecs()

2018-11-20 Thread Sagi Grimberg
Yeah, that is the most common example, given merge is enabled in most of cases. If the driver or device doesn't care merge, you can disable it and always get single bio request, then the bio's bvec table can be reused for send(). Does bvec_iter span bvecs with your patches? I didn't see that

Re: [dm-devel] [PATCH V10 09/19] block: introduce bio_bvecs()

2018-11-20 Thread Sagi Grimberg
I would like to avoid growing bvec tables and keep everything preallocated. Plus, a bvec_iter operates on a bvec which means we'll need a table there as well... Not liking it so far... In case of bios in one request, we can't know how many bvecs there are except for calling rq_bvecs(), so it

Re: [dm-devel] [PATCH V10 09/19] block: introduce bio_bvecs()

2018-11-20 Thread Ming Lei
On Tue, Nov 20, 2018 at 07:20:45PM -0800, Sagi Grimberg wrote: > > > Not sure I understand the 'blocking' problem in this case. > > > > We can build a bvec table from this req, and send them all > > in send(), > > I would like to avoid growing bvec tables and keep everything > preallocated.

Re: [dm-devel] [PATCH V10 09/19] block: introduce bio_bvecs()

2018-11-20 Thread Sagi Grimberg
Not sure I understand the 'blocking' problem in this case. We can build a bvec table from this req, and send them all in send(), I would like to avoid growing bvec tables and keep everything preallocated. Plus, a bvec_iter operates on a bvec which means we'll need a table there as well...

Re: [dm-devel] [PATCH V10 09/19] block: introduce bio_bvecs()

2018-11-20 Thread Ming Lei
On Tue, Nov 20, 2018 at 12:11:35PM -0800, Sagi Grimberg wrote: > > > > > The only user in your final tree seems to be the loop driver, and > > > > even that one only uses the helper for read/write bios. > > > > > > > > I think something like this would be much simpler in the end: > > > > > >

Re: [dm-devel] [PATCH V10 09/19] block: introduce bio_bvecs()

2018-11-20 Thread Sagi Grimberg
The only user in your final tree seems to be the loop driver, and even that one only uses the helper for read/write bios. I think something like this would be much simpler in the end: The recently submitted nvme-tcp host driver should also be a user of this. Does it make sense to keep it as

Re: [dm-devel] [PATCH V10 09/19] block: introduce bio_bvecs()

2018-11-20 Thread Christoph Hellwig
On Mon, Nov 19, 2018 at 04:49:27PM -0800, Sagi Grimberg wrote: > >> The only user in your final tree seems to be the loop driver, and >> even that one only uses the helper for read/write bios. >> >> I think something like this would be much simpler in the end: > > The recently submitted nvme-tcp

Re: [dm-devel] [PATCH V10 09/19] block: introduce bio_bvecs()

2018-11-19 Thread Sagi Grimberg
The only user in your final tree seems to be the loop driver, and even that one only uses the helper for read/write bios. I think something like this would be much simpler in the end: The recently submitted nvme-tcp host driver should also be a user of this. Does it make sense to keep it as

Re: [dm-devel] [PATCH V10 09/19] block: introduce bio_bvecs()

2018-11-16 Thread Christoph Hellwig
On Thu, Nov 15, 2018 at 04:52:56PM +0800, Ming Lei wrote: > There are still cases in which we need to use bio_bvecs() for get the > number of multi-page segment, so introduce it. The only user in your final tree seems to be the loop driver, and even that one only uses the helper for read/write

Re: [dm-devel] [PATCH V10 09/19] block: introduce bio_bvecs()

2018-11-16 Thread Omar Sandoval
On Thu, Nov 15, 2018 at 04:52:56PM +0800, Ming Lei wrote: > There are still cases in which we need to use bio_bvecs() for get the > number of multi-page segment, so introduce it. > > Cc: Dave Chinner > Cc: Kent Overstreet > Cc: Mike Snitzer > Cc: dm-devel@redhat.com > Cc: Alexander Viro > Cc:

[dm-devel] [PATCH V10 09/19] block: introduce bio_bvecs()

2018-11-15 Thread Ming Lei
There are still cases in which we need to use bio_bvecs() for get the number of multi-page segment, so introduce it. Cc: Dave Chinner Cc: Kent Overstreet Cc: Mike Snitzer Cc: dm-devel@redhat.com Cc: Alexander Viro Cc: linux-fsde...@vger.kernel.org Cc: Shaohua Li Cc: