Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 8 Jun 2023 17:38:17 +0530
From:   Nitesh Shetty <nj.shetty@samsung.com>
To:     Christoph Hellwig <hch@infradead.org>,
        "Martin K. Petersen" <martin.petersen@oracle.com>
Cc:     Jens Axboe <axboe@kernel.dk>, Jonathan Corbet <corbet@lwn.net>,
        Alasdair Kergon <agk@redhat.com>,
        Mike Snitzer <snitzer@kernel.org>, dm-devel@redhat.com,
        Keith Busch <kbusch@kernel.org>,
        Christoph Hellwig <hch@lst.de>,
        Sagi Grimberg <sagi@grimberg.me>,
        James Smart <james.smart@broadcom.com>,
        Chaitanya Kulkarni <kch@nvidia.com>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        Christian Brauner <brauner@kernel.org>,
        martin.petersen@oracle.com, linux-scsi@vger.kernel.org,
        willy@infradead.org, hare@suse.de, djwong@kernel.org,
        bvanassche@acm.org, ming.lei@redhat.com, dlemoal@kernel.org,
        nitheshshetty@gmail.com, gost.dev@samsung.com,
        Kanchan Joshi <joshi.k@samsung.com>,
        Javier =?utf-8?B?R29uesOhbGV6?= <javier.gonz@samsung.com>,
        Anuj Gupta <anuj20.g@samsung.com>, linux-block@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
        linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v12 5/9] nvme: add copy offload support
Message-ID: <20230608120817.jg4xb4jhg77mlksw@green245>
MIME-Version: 1.0
In-Reply-To: <ZIAt7vL+/isPJEl5@infradead.org>
User-Agent: NeoMutt/20171215
Content-Type: multipart/mixed;
        boundary="----RbnLpepSOhDWt1JmDV6HMUWO9Dmn-C3OOrycHY1seGoKI43i=_57f1d_"
CMS-TYPE: 105P
DLP-Filter: Pass
References: <20230605121732.28468-1-nj.shetty@samsung.com>
        <CGME20230605122310epcas5p4aaebfc26fe5377613a36fe50423cf494@epcas5p4.samsung.com>
        <20230605121732.28468-6-nj.shetty@samsung.com>
        <ZH3mjUb+yqI11XD8@infradead.org> <20230606113535.rjbhe6eqlyqk4pqq@green245>
        <ZIAt7vL+/isPJEl5@infradead.org>
Precedence: bulk

------RbnLpepSOhDWt1JmDV6HMUWO9Dmn-C3OOrycHY1seGoKI43i=_57f1d_
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Disposition: inline

Hi Christoph and Martin,

On 23/06/07 12:12AM, Christoph Hellwig wrote:
>On Tue, Jun 06, 2023 at 05:05:35PM +0530, Nitesh Shetty wrote:
>> Downside will be duplicating checks which are present for read, write in
>> block layer, device-mapper and zoned devices.
>> But we can do this, shouldn't be an issue.
>
>Yes.  Please never overload operations, this is just causing problems
>everywhere, and that why I split the operations from the flag a few
>years ago.
>

Sure, we will add REQ_COPY_IN/OUT and send a new version.

>> The idea behind subsys is to prevent copy across different subsystem.
>> For example, copy across nvme subsystem and the scsi subsystem. [1]
>> At present, we don't support inter-namespace(copy across NVMe namespace),
>> but after community feedback for previous series we left scope for it.
>
>Never leave scope for something that isn't actually added.  That just
>creates a giant maintainance nightmare.  Cross-device copies are giant
>nightmare in general, and in the case of NVMe completely unusable
>as currently done in the working group.  Messing up something that
>is entirely reasonable (local copy) for something like that is a sure
>way to never get this series in.

Sure, we can do away with subsys and realign more on single namespace copy.
We are planning to use token to store source info, such as src sector,
len and namespace. Something like below,

struct nvme_copy_token {
	struct nvme_ns *ns; // to make sure we are copying within same namespace
/* store source info during *IN operation, will be used by *OUT operation */
	sector_t src_sector;
	sector_t sectors;
};
Do you have any better way to handle this in mind ?


Thank you,
Nitesh Shetty

------RbnLpepSOhDWt1JmDV6HMUWO9Dmn-C3OOrycHY1seGoKI43i=_57f1d_
Content-Type: text/plain; charset="utf-8"


------RbnLpepSOhDWt1JmDV6HMUWO9Dmn-C3OOrycHY1seGoKI43i=_57f1d_--