Received: by 2002:ab2:7903:0:b0:1fb:b500:807b with SMTP id a3csp1426473lqj; Tue, 4 Jun 2024 00:39:46 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVL9xoDV7dlisn8EwsfBscDrwAjO2tdBG4e43l+RTvrxMCMu9B9a9Nj7FdbHiP2JcLLu3tQK41PpCsewdraumNZ4JWCfpLBEG/Yktc5SA== X-Google-Smtp-Source: AGHT+IHbIwSrwdKvLYCo2WOzz3JCgDtxSC30QWESuSHhlEMetdDDDavLy8/kw/G/OsHgP8U1D5H0 X-Received: by 2002:a05:620a:4047:b0:792:bf4d:6e8b with SMTP id af79cd13be357-794f5c64b17mr1487356685a.14.1717486786314; Tue, 04 Jun 2024 00:39:46 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1717486786; cv=pass; d=google.com; s=arc-20160816; b=vowbPGv1OLXDT4fb8Ha1HCyrcXxVtdM7iQxne18kdpK5vn1ZLn45/6hVVtbmeKbf8J LaUYIdzKLvhDKH8Sf3XjP9Ke3pG+3CheoFG3CqFCWHketSwlVil0wtQiR34Sc5+7+Njq BhUJrLK5kDl+kynRXbjMlcs1Gk7U9eDasVNDEAYCC1+wP6ZcJB5ym3egOfgYlPH7XZ2o LwIVpFfpp03OjrUKJTZjnGotf+sRDzn3AI1SgRvxxcRIJni6P8YaulS4kW0OTaRmmKlL iIL02fPwtLTff9q+d3yWd+SmRYKv1lzfA6LGqfUeRl+1nX5aOouXI+86xLAc7tTGBAmO R40w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:organization:content-language :from:references:cc:to:subject:user-agent:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:date:message-id :dkim-signature; bh=R2qcYpI0mFvLOvr2gk3eng5jTPbZVJ51W4GKMgvY9to=; fh=raBsGy/d4tpTL7/FsfWPLJcZ2A7B9gSluRQzzHMmwn0=; b=O1/QbFKzMruYXQZWOpMQPiL+df6kI03XE7QJv7TndCeLABktmH0o3kTw7Yq5mZH0JC uW/9IbKA8hZLBHPuHkJ00/xEcw7b7LFhIgamCrUIao6qfU6py3BaS7Cm4pQ8Fllm2dr2 7Nu9B6nQHuSnnVtpFcsu1Iq/nVrswmWpQOP28nKS4zz5cpfHAefPIja/FyvGWSdqjw9W 1LlUW/h9XTYBSR4gQ7UTrYiEi+f0HNoSeL/ZCwGCoAmG+q1fVP7cgCrs8pNM0blOdvzq o6nLg6ddgozvvqLDuPAk8ZEanLchvGu2E6k5iZCbbkcPCaNsxulP9rQZsCV9NC1GwCvd dthQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=GI261o57; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-200168-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-200168-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id d75a77b69052e-43ff259f58bsi25103081cf.664.2024.06.04.00.39.46 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Jun 2024 00:39:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-200168-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=GI261o57; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-200168-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-200168-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 119A01C20CBF for ; Tue, 4 Jun 2024 07:39:46 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4864F1411F2; Tue, 4 Jun 2024 07:39:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GI261o57" 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 4680F1EB30; Tue, 4 Jun 2024 07:39:30 +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=1717486771; cv=none; b=FdzOn4M3TR9xulbXJGtnZrZPFYA+DHn6tVjGZvTKPouJLEDNWlGgfXyNJYITQUJA0K6VFiyDDVc8ZQK6plrPNWL7pvfLvg+xSqo2LfPF/hsMzsR+DwUPhkzmye8/nb7FnAJLmVwrYyDjlztILYUV35AsIANClfL8E7Ah3HSrS0s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717486771; c=relaxed/simple; bh=IwRk73FI7oCSvA9GoThk9eEnhOPDGRbbqcPOdPVc2Uw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qUzx9cG0SUqbRDiM/U2xVcpFMCV2roMQJ9RZOqPEBgz8PioWDzB+rSaoDmNpVStQ1YywYe+GAAGBiv0HSEN9Ok+VmmfAqFQi4lcpA4Pit7uMlqqjUcVFByDtc/GPYLT6e+hPzr51LNyZN+Us3yxgkCkz866GysabXcHyNirkuVI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GI261o57; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 11995C32782; Tue, 4 Jun 2024 07:39:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717486770; bh=IwRk73FI7oCSvA9GoThk9eEnhOPDGRbbqcPOdPVc2Uw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=GI261o576gg25/lggqNDA2SfXlSJn3QRY7AGVwcyAmBUOY2+2/Skb/bS1BUCh9qWl QKz3Jh5M82o5F/6PUgsBq0Gsh7DHrbgUxYPptG+VI9WDVVcsarzvpz92mvCFUSRn4w dsA3PAUnRTIlKggNkbrr+yewxURwwu2pgA4udfQ7PsravITSz0hF0RNkvPEsXjrDW0 wgwdLoaBdgKRYI4xl7pgSc9vSh2CdAzwjhxH4xcArykbw0zJHnERyQlz+xAu/TMLtL Yd9pQ9MINSEdazBen1lLjskybIkbgnHTDxCdtLFQWOH/x3vJ71IiKQwnw36Gv4Ljfd jhhldACaNEbJQ== Message-ID: <5441b256-494a-4344-89fd-ee8c5a073f8b@kernel.org> Date: Tue, 4 Jun 2024 16:39:25 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v20 00/12] Implement copy offload support To: Hannes Reinecke , Christoph Hellwig , Nitesh Shetty Cc: Jens Axboe , Jonathan Corbet , Alasdair Kergon , Mike Snitzer , Mikulas Patocka , Keith Busch , Sagi Grimberg , Chaitanya Kulkarni , Alexander Viro , Christian Brauner , Jan Kara , martin.petersen@oracle.com, bvanassche@acm.org, david@fromorbit.com, 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 References: <20240604043242.GC28886@lst.de> <393edf87-30c9-48b8-b703-4b8e514ac4d9@suse.de> From: Damien Le Moal Content-Language: en-US Organization: Western Digital Research In-Reply-To: <393edf87-30c9-48b8-b703-4b8e514ac4d9@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 6/4/24 16:16, Hannes Reinecke wrote: > On 6/4/24 06:32, Christoph Hellwig wrote: >> On Mon, Jun 03, 2024 at 10:53:39AM +0000, Nitesh Shetty wrote: >>> The major benefit of this copy-offload/emulation framework is >>> observed in fabrics setup, for copy workloads across the network. >>> The host will send offload command over the network and actual copy >>> can be achieved using emulation on the target (hence patch 4). >>> This results in higher performance and lower network consumption, >>> as compared to read and write travelling across the network. >>> With this design of copy-offload/emulation we are able to see the >>> following improvements as compared to userspace read + write on a >>> NVMeOF TCP setup: >> >> What is the use case of this? What workloads does raw copies a lot >> of data inside a single block device? >> > > The canonical example would be VM provisioning from a master copy. > That's not within a single block device, mind; that's more for copying > the contents of one device to another. Wouldn't such use case more likely to use file copy ? I have not heard a lot of cases where VM images occupy an entire block device, but I may be mistaken here... > But I wasn't aware that this approach is limited to copying within a > single block devices; that would be quite pointless indeed. Not pointless for any FS doing CoW+Rebalancing of block groups (e.g. btrfs) and of course GC for FSes on zoned devices. But for this use case, an API allowing multiple sources and one destination would be better. -- Damien Le Moal Western Digital Research