Re: [dm-devel] [PATCH 3/7] block: copy offload support infrastructure

From: Kanchan Joshi <joshiiitr@gmail.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: snitzer@redhat.com, djwong@kernel.org,
	linux-nvme@lists.infradead.org, dm-devel@redhat.com,
	Christoph Hellwig <hch@lst.de>,
	agk@redhat.com, bvanassche@acm.org, linux-scsi@vger.kernel.org,
	nitheshshetty@gmail.com, Matthew Wilcox <willy@infradead.org>,
	Nitesh Shetty <nj.shetty@samsung.com>,
	kch@kernel.org, SelvaKumar S <selvakuma.s1@samsung.com>,
	Selva Jove <selvajove@gmail.com>,
	linux-block@vger.kernel.org, mpatocka@redhat.com,
	Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@kernel.dk>,
	Damien Le Moal <damien.lemoal@wdc.com>,
	KANCHAN JOSHI <joshi.k@samsung.com>,
	linux-api@vger.kernel.org,
	Johannes Thumshirn <johannes.thumshirn@wdc.com>,
	linux-fsdevel@vger.kernel.org,
	Javier Gonzalez <javier.gonz@samsung.com>,
	Pavel Begunkov <asml.silence@gmail.com>
Subject: Re: [dm-devel] [PATCH 3/7] block: copy offload support infrastructure
Date: Fri, 20 Aug 2021 16:41:15 +0530	[thread overview]
Message-ID: <CA+1E3rKmS6LSPDb9C8S7Ap-b40TB9dfogC-PYm7ehLeBTn+Ukw@mail.gmail.com> (raw)
In-Reply-To: <yq1sfz6loh9.fsf@ca-mkp.ca.oracle.com>

On Thu, Aug 19, 2021 at 12:05 AM Martin K. Petersen
<martin.petersen@oracle.com> wrote:
>
>
> > Native copy offload is not supported for stacked devices.
>
> One of the main reasons that the historic attempts at supporting copy
> offload did not get merged was that the ubiquitous deployment scenario,
> stacked block devices, was not handled well.
>
> Pitfalls surrounding stacking has been brought up several times in
> response to your series. It is critically important that both kernel
> plumbing and user-facing interfaces are defined in a way that works for
> the most common use cases. This includes copying between block devices
> and handling block device stacking. Stacking being one of the most
> fundamental operating principles of the Linux block layer!
>
> Proposing a brand new interface that out of the gate is incompatible
> with both stacking and the copy offload capability widely implemented in
> shipping hardware makes little sense. While NVMe currently only supports
> copy operations inside a single namespace, it is surely only a matter of
> time before that restriction is lifted.
>
> Changing existing interfaces is painful, especially when these are
> exposed to userland. We obviously can't predict every field or feature
> that may be needed in the future. But we should at the very least build
> the infrastructure around what already exists. And that's where the
> proposed design falls short...
>
Certainly, on user-space interface. We've got few cracks to be filled
there, missing the future viability.
But on stacking, can that be additive. Could you please take a look at
the other response (comment from Bart) for the trade-offs.


-- 
Joshi

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel