From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CCF151A254A; Mon, 24 Jun 2024 22:58:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719269905; cv=none; b=FDEa5iKgXpamGEvgrIv0TXZA0zklAL/AL7bFAyABp2EjKE/qTKPVJX3aX7zBZM8dxxAdKYAr+oz+0s0KyfBk9vWTuiZyZV7j55kce4KrPdGkG5Kf5HMcrgIREG/d8YUB4KZXUFziAWK0xmWTAlni4NfkoWXjyEEnvNZaq6kKA+Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719269905; c=relaxed/simple; bh=iA7soJkpGVIKt7XVvk8Avygo72QDsaSjKA52TLDa3y4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=URc6vSgslW+dcyjRN9juuWhGRfDdGunBGkF8nEfadyVxE/U6pOZGpka81dIKh2Il1nxJMr6skOUGVe+Za1XK0zwNP99x+/SYBsas/FR08ZAQVYs+ImJr/E2/U/ZiZ8dHPcI0uzjEUdGaZmWeTEmKH7s/pe8TcF2DWYSzofVAZhU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cIgX487J; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cIgX487J" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53667C2BBFC; Mon, 24 Jun 2024 22:58:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1719269904; bh=iA7soJkpGVIKt7XVvk8Avygo72QDsaSjKA52TLDa3y4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cIgX487JN8lhIWwtdU5liMps5jnB/iuFfCdxzShBm0+k16Zc6TUnzq5B+IfX9ao9h bvCAPx5R4d2FID4jv+PXsrL3rU+CdxSXD0FEz55Yytha/MVXjP4qDCMIOV76mfGvUK RzGVX3+vG7RP3qfmNcGzcY77s6ybP1HFlnIdfemDqWPpp9e6OAcDCjkcf7enJbDEf8 z/T3Hgac1qVPR5zIsLevzeNCOVA2NJzbYir9lUyWmKJLRPzp9Z+AUFtGO0zgS3MJx/ CQS1ogR3PouW+eiO0maCC1Dwix1Dx4KUlCAD21OPYpzKHeecDTqvnNx0TENlrK+VwA cR4rL1FSGnaMw== Date: Mon, 24 Jun 2024 16:58:19 -0600 From: Keith Busch To: Nitesh Shetty Cc: Christoph Hellwig , Bart Van Assche , Damien Le Moal , Jens Axboe , Jonathan Corbet , Alasdair Kergon , Mike Snitzer , Mikulas Patocka , Sagi Grimberg , Chaitanya Kulkarni , Alexander Viro , Christian Brauner , Jan Kara , martin.petersen@oracle.com, david@fromorbit.com, hare@suse.de, damien.lemoal@opensource.wdc.com, anuj20.g@samsung.com, joshi.k@samsung.com, nitheshshetty@gmail.com, gost.dev@samsung.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, dm-devel@lists.linux.dev, linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v20 02/12] Add infrastructure for copy offload in block and request layer. Message-ID: References: <665850bd.050a0220.a5e6b.5b72SMTPIN_ADDED_BROKEN@mx.google.com> <20240601055931.GB5772@lst.de> <20240604044042.GA29094@lst.de> <4ffad358-a3e6-4a88-9a40-b7e5d05aa53c@acm.org> <20240605082028.GC18688@lst.de> <66795280.630a0220.f3ccd.b80cSMTPIN_ADDED_BROKEN@mx.google.com> Precedence: bulk X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66795280.630a0220.f3ccd.b80cSMTPIN_ADDED_BROKEN@mx.google.com> On Mon, Jun 24, 2024 at 04:14:07PM +0530, Nitesh Shetty wrote: > c. List/ctx based approach: > A new member is added to bio, bio_copy_ctx, which will a union with > bi_integrity. Idea is once a copy bio reaches blk_mq_submit_bio, it will > add the bio to this list. Is there a reason to tie this to CONFIG_BLK_DEV_INTEGRITY? Why not use the bio_io_vec? There's no user data here, so that's unused, right? > 1. Send the destination BIO, once this reaches blk_mq_submit_bio, this > will add the destination BIO to the list inside bi_copy_ctx and return > without forming any request. > 2. Send source BIO, once this reaches blk_mq_submit_bio, this will > retrieve the destination BIO from bi_copy_ctx and form a request with > destination BIO and source BIO. After this request will be sent to > driver. Like Damien, I also don't see the point of the 2-bio requirement. Treat it like discard, and drivers can allocate "special".