[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOSviJ1b5ySAugzKExa_ZQgOzvQAOWB3D-ZRMQeGmNpQbaoBSQ@mail.gmail.com>
Date: Mon, 14 Aug 2023 22:25:54 +0530
From: Nitesh Shetty <nitheshshetty@...il.com>
To: Bart Van Assche <bvanassche@....org>
Cc: Nitesh Shetty <nj.shetty@...sung.com>,
Jens Axboe <axboe@...nel.dk>, Jonathan Corbet <corbet@....net>,
Alasdair Kergon <agk@...hat.com>,
Mike Snitzer <snitzer@...nel.org>, dm-devel@...hat.com,
Keith Busch <kbusch@...nel.org>,
Christoph Hellwig <hch@....de>,
Sagi Grimberg <sagi@...mberg.me>,
Chaitanya Kulkarni <kch@...dia.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>,
martin.petersen@...cle.com, linux-doc@...r.kernel.org,
gost.dev@...sung.com, linux-kernel@...r.kernel.org,
linux-nvme@...ts.infradead.org, linux-block@...r.kernel.org,
mcgrof@...nel.org, dlemoal@...nel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [dm-devel] [PATCH v14 00/11] Implement copy offload support
On Sat, Aug 12, 2023 at 3:42 AM Bart Van Assche <bvanassche@....org> wrote:
>
> On 8/11/23 03:52, Nitesh Shetty wrote:
> > We achieve copy offload by sending 2 bio's with source and destination
> > info and merge them to form a request. This request is sent to driver.
> > So this design works only for request based storage drivers.
>
> [ ... ]
>
> > Overall series supports:
> > ========================
> > 1. Driver
> > - NVMe Copy command (single NS, TP 4065), including support
> > in nvme-target (for block and file back end).
> >
> > 2. Block layer
> > - Block-generic copy (REQ_OP_COPY_DST/SRC), operation with
> > interface accommodating two block-devs
> > - Merging copy requests in request layer
> > - Emulation, for in-kernel user when offload is natively
> > absent
> > - dm-linear support (for cases not requiring split)
> >
> > 3. User-interface
> > - copy_file_range
>
> Is this sufficient? The combination of dm-crypt, dm-linear and the NVMe
> driver is very common. What is the plan for supporting dm-crypt?
Plan is to add offload support for other dm targets as part of subsequent
series once current patchset merges, dm targets can use emulation to
achieve the same at present.
> Shouldn't bio splitting be supported for dm-linear?
Handling split is tricky in this case, if we allow splitting, there is
no easy way
to match/merge different src/dst bio's. Once we have multi range support then
we feel at least src bio's can be split. But this series split won't work.
Thank you,
Nitesh Shetty
Powered by blists - more mailing lists