From: "Javier González" <javier.gonz@samsung.com>
To: Chaitanya Kulkarni <chaitanyak@nvidia.com>
Cc: Vincent Fu <vincent.fu@samsung.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
Adam Manzanares <a.manzanares@samsung.com>,
"osandov@fb.com" <osandov@fb.com>,
"msnitzer@redhat.com" <msnitzer@redhat.com>,
"bvanassche@acm.org" <bvanassche@acm.org>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"hch@lst.de" <hch@lst.de>,
"roland@purestorage.com" <roland@purestorage.com>,
Nitesh Shetty <nj.shetty@samsung.com>,
"zach.brown@ni.com" <zach.brown@ni.com>,
SelvaKumar S <selvakuma.s1@samsung.com>,
Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"mpatocka@redhat.com" <mpatocka@redhat.com>,
"kbusch@kernel.org" <kbusch@kernel.org>,
"Frederick.Knight@netapp.com" <Frederick.Knight@netapp.com>,
"axboe@kernel.dk" <axboe@kernel.dk>,
Kanchan Joshi <joshi.k@samsung.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
"rwheeler@redhat.com" <rwheeler@redhat.com>
Subject: Re: [dm-devel] [LSF/MM/BFP ATTEND] [LSF/MM/BFP TOPIC] Storage: Copy Offload
Date: Wed, 13 Oct 2021 10:35:33 +0200 [thread overview]
Message-ID: <20211013083533.hhgrkm3lhoytfp3a@mpHalley-2.domain_not_set.invalid> (raw)
In-Reply-To: <20211006100121.2hqfdkyuivzvzd33@mpHalley.domain_not_set.invalid>
Chaitanya,
Did you have a chance to look at the answers below?
I would like to start finding candidate dates throughout the next couple
of weeks.
Thanks,
Javier
On 06.10.2021 12:01, Javier González wrote:
>On 30.09.2021 09:43, Chaitanya Kulkarni wrote:
>>Javier,
>>
>>>
>>>Hi all,
>>>
>>>Since we are not going to be able to talk about this at LSF/MM, a few of
>>>us thought about holding a dedicated virtual discussion about Copy
>>>Offload. I believe we can use Chaitanya's thread as a start. Given the
>>>current state of the current patches, I would propose that we focus on
>>>the next step to get the minimal patchset that can go upstream so that
>>>we can build from there.
>>>
>>
>>I agree with having a call as it has been two years I'm trying to have
>>this discussion.
>>
>>Before we setup a call, please summarize following here :-
>>
>>1. Exactly what work has been done so far.
>
>
>We can categorize that into two sets. First one for XCopy (2014), and
>second one for NVMe Copy (2021).
>
>XCOPY set *********
>- block-generic copy command (single range, between one
> source/destination device)
>- ioctl interface for the above
>- SCSI plumbing (block-generic to XCOPY conversion)
>- device-mapper support: offload copy whenever possible (if IO is not
> split while traveling layers of virtual devices)
>
>NVMe-Copy set *************
>- block-generic copy command (multiple ranges, between one
> source/destination device)
>- ioctl interface for the above
>- NVMe plumbing (block-generic to NVMe Copy conversion)
>- copy-emulation (read + write) in block-layer
>- device-mapper support: no offload, rather fall back to copy-emulation
>
>
>>2. What kind of feedback you got.
>
>For NVMe Copy, the major points are - a) add copy-emulation in
>block-layer and use that if copy-offload is not natively supported by
>device b) user-interface (ioctl) should be extendable for copy across
>two devices (one source, one destination) c) device-mapper targets
>should support copy-offload, whenever possible
>
>"whenever possible" cases get reduced compared to XCOPY because NVMe
>Copy is wit
>
>>3. What are the exact blockers/objections.
>
>I think it was device-mapper for XCOPY and remains the same for NVMe
>Copy as well. Device-mapper support requires decomposing copy operation
>to read and write. While that is not great for efficiency PoV, bigger
>concern is to check if we are taking the same route as XCOPY.
>
>From Martin's document (http://mkp.net/pubs/xcopy.pdf), if I got it
>right, one the major blocker is having more failure cases than
>successful ones. And that did not justify the effort/code to wire up
>device mapper. Is that a factor to consider for NVMe Copy (which is
>narrower in scope than XCOPY).
>
>>4. Potential ways of moving forward.
>
>a) we defer attempt device-mapper support (until NVMe has
>support/usecase), and address everything else (reusable user-interface
>etc.)
>
>b) we attempt device-mapper support (by moving to composite read+write
>communication between block-layer and nvme)
>
>
>Is this enough in your mind to move forward with a specific agenda? If
>we can, I would like to target the meetup in the next 2 weeks.
>
>Thanks,
>Javier
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2021-10-14 7:53 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-11 0:15 [dm-devel] [LSF/MM/BFP ATTEND] [LSF/MM/BFP TOPIC] Storage: Copy Offload Chaitanya Kulkarni
2021-05-11 21:15 ` Knight, Frederick
2021-05-12 2:21 ` Bart Van Assche
[not found] ` <CGME20210512071321eucas1p2ca2253e90449108b9f3e4689bf8e0512@eucas1p2.samsung.com>
2021-05-12 7:13 ` Javier González
2021-05-12 7:30 ` Johannes Thumshirn
[not found] ` <CGME20210928191342eucas1p23448dcd51b23495fa67cdc017e77435c@eucas1p2.samsung.com>
2021-09-28 19:13 ` Javier González
2021-09-29 6:44 ` Johannes Thumshirn
2021-09-30 9:43 ` Chaitanya Kulkarni
2021-09-30 9:53 ` Javier González
2021-10-06 10:01 ` Javier González
2021-10-13 8:35 ` Javier González [this message]
2021-09-30 16:20 ` Bart Van Assche
2021-10-06 10:05 ` Javier González
2021-10-06 17:33 ` Bart Van Assche
[not found] ` <20211008064925.oyjxbmngghr2yovr@mpHalley.local>
2021-10-29 0:21 ` Chaitanya Kulkarni
2021-10-29 5:51 ` Hannes Reinecke
2021-10-29 8:16 ` Javier González
2021-10-29 16:15 ` Bart Van Assche
2021-11-01 17:54 ` Keith Busch
2021-10-29 8:14 ` Javier González
2021-11-03 19:27 ` Javier González
[not found] ` <20211116134324.hbs3tp5proxootd7@ArmHalley.localdomain>
2021-11-16 17:59 ` Bart Van Assche
[not found] ` <20211117125224.z36hp2crpj4fwngc@ArmHalley.local>
2021-11-17 15:52 ` Bart Van Assche
[not found] ` <CA+1E3rJRT+89OCyqRtb5BFbez0BfkKvCGijd=nObMEB3_v6MyA@mail.gmail.com>
2021-11-19 16:21 ` Bart Van Assche
2021-05-12 7:36 ` Erwin van Londen
2021-05-12 15:23 ` Hannes Reinecke
2021-05-12 15:45 ` Himanshu Madhani
2021-05-17 16:39 ` Kanchan Joshi
2021-05-18 0:15 ` Bart Van Assche
2021-06-11 6:03 ` Chaitanya Kulkarni
2021-06-11 15:35 ` Nikos Tsironis
[not found] <CGME20220127071544uscas1p2f70f4d2509f3ebd574b7ed746d3fa551@uscas1p2.samsung.com>
[not found] ` <f0e19ae4-b37a-e9a3-2be7-a5afb334a5c3@nvidia.com>
2022-01-28 19:59 ` Adam Manzanares
2022-01-31 11:49 ` Johannes Thumshirn
2022-01-31 19:03 ` Bart Van Assche
2022-02-01 1:54 ` Luis Chamberlain
2022-02-02 5:57 ` Kanchan Joshi
[not found] ` <20220201102122.4okwj2gipjbvuyux@mpHalley-2>
2022-02-07 9:57 ` Nitesh Shetty
2022-02-07 10:45 ` David Disseldorp
2022-03-01 17:34 ` Nikos Tsironis
[not found] ` <c4124f39-1ee9-8f34-e731-42315fee15f9@nvidia.com>
2022-03-03 18:36 ` Nikos Tsironis
2022-03-08 20:48 ` Nikos Tsironis
2022-03-09 8:51 ` Mikulas Patocka
2022-03-09 15:49 ` Nikos Tsironis
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=20211013083533.hhgrkm3lhoytfp3a@mpHalley-2.domain_not_set.invalid \
--to=javier.gonz@samsung.com \
--cc=Chaitanya.Kulkarni@wdc.com \
--cc=Frederick.Knight@netapp.com \
--cc=Johannes.Thumshirn@wdc.com \
--cc=a.manzanares@samsung.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=chaitanyak@nvidia.com \
--cc=dm-devel@redhat.com \
--cc=hch@lst.de \
--cc=joshi.k@samsung.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=martin.petersen@oracle.com \
--cc=mpatocka@redhat.com \
--cc=msnitzer@redhat.com \
--cc=nj.shetty@samsung.com \
--cc=osandov@fb.com \
--cc=roland@purestorage.com \
--cc=rwheeler@redhat.com \
--cc=selvakuma.s1@samsung.com \
--cc=vincent.fu@samsung.com \
--cc=zach.brown@ni.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).