[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y33UAp6ncSPO84XI@T590>
Date: Wed, 23 Nov 2022 16:04:18 +0800
From: Ming Lei <ming.lei@...hat.com>
To: Nitesh Shetty <nj.shetty@...sung.com>
Cc: axboe@...nel.dk, agk@...hat.com, snitzer@...nel.org,
dm-devel@...hat.com, kbusch@...nel.org, hch@....de,
sagi@...mberg.me, james.smart@...adcom.com, kch@...dia.com,
damien.lemoal@...nsource.wdc.com, naohiro.aota@....com,
jth@...nel.org, viro@...iv.linux.org.uk,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-nvme@...ts.infradead.org, linux-fsdevel@...r.kernel.org,
anuj20.g@...sung.com, joshi.k@...sung.com, p.raghav@...sung.com,
nitheshshetty@...il.com, gost.dev@...sung.com, ming.lei@...hat.com
Subject: Re: [PATCH v5 02/10] block: Add copy offload support infrastructure
On Wed, Nov 23, 2022 at 11:28:19AM +0530, Nitesh Shetty wrote:
> Introduce blkdev_issue_copy which supports source and destination bdevs,
> and an array of (source, destination and copy length) tuples.
> Introduce REQ_COPY copy offload operation flag. Create a read-write
> bio pair with a token as payload and submitted to the device in order.
> Read request populates token with source specific information which
> is then passed with write request.
> This design is courtesy Mikulas Patocka's token based copy
I thought this patchset is just for enabling copy command which is
supported by hardware. But turns out it isn't, because blk_copy_offload()
still submits read/write bios for doing the copy.
I am just wondering why not let copy_file_range() cover this kind of copy,
and the framework has been there.
When I was researching pipe/splice code for supporting ublk zero copy[1], I
have got idea for async copy_file_range(), such as: io uring based
direct splice, user backed intermediate buffer, still zero copy, if these
ideas are finally implemented, we could get super-fast generic offload copy,
and bdev copy is really covered too.
[1] https://lore.kernel.org/linux-block/20221103085004.1029763-1-ming.lei@redhat.com/
thanks,
Ming
Powered by blists - more mailing lists