From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B2D5AC25B74 for ; Tue, 4 Jun 2024 03:29:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:References:Content-Type: In-Reply-To:MIME-Version:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7VN6ZUoN/sVx9OFQYPCvCDso3Uou5inchmMvd4vuq5E=; b=MCaiTl9XEtetwdTL7+CoHtW/Dn UQ/pC1IzFqzM1bNsTrXoNCvAPBGtsd5r6694CN2KUsJVfecpTox2y/zqzF6f0KvzELkkRcbk1H0jc cKB3oyTGgjo9UE/iymUcjGxp6hUKCaNjSeVc/E7Na6zLQEWbedq9oJJa/QoVgMetaOD5xNi+l8E+S xUnaw6tfMS3qU+GcYBmhkaMOYB67RuN0w2NtT0qEYSxoZCw5J5SIs9H+u0YqRW6hkeLNHCkP2XGKe 7ltooEjxKI4WaxZQ/mUvX3YkuRXPNMYsQcZ4ntv2yRWjKP8KHLxjlURE8rufIaxeUxtb9W4KQkOSz ANC/wkLQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sEKr4-000000012Uh-23AD; Tue, 04 Jun 2024 03:28:58 +0000 Received: from mailout2.samsung.com ([203.254.224.25]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sEKqz-000000012TD-3T1T for linux-nvme@lists.infradead.org; Tue, 04 Jun 2024 03:28:57 +0000 Received: from epcas5p3.samsung.com (unknown [182.195.41.41]) by mailout2.samsung.com (KnoxPortal) with ESMTP id 20240604032847epoutp02a70620567c4fa4377c89c95d3f162975~Vr2_9Zk9b3006130061epoutp02W for ; Tue, 4 Jun 2024 03:28:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.samsung.com 20240604032847epoutp02a70620567c4fa4377c89c95d3f162975~Vr2_9Zk9b3006130061epoutp02W DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1717471727; bh=7VN6ZUoN/sVx9OFQYPCvCDso3Uou5inchmMvd4vuq5E=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=tNcvNOlRXnI5bedxJ26y9w6TRzG50YcynA+2cGwniUTGpbgpPHphBAsVudbrcN6WS Fpv7ucxsfE765eTLhxyisAVREhNHMPqO/FB5cH81xO6io/wNvfYuyBtGTssgD1G/vj 9fPq3lfnRj7akJXFtacojDMp/JpXoMaqAMTH/PV8= Received: from epsnrtp2.localdomain (unknown [182.195.42.163]) by epcas5p1.samsung.com (KnoxPortal) with ESMTP id 20240604032846epcas5p1f1c03e377b238d49df5eb58251bf4543~Vr29wVx_50292302923epcas5p1T; Tue, 4 Jun 2024 03:28:46 +0000 (GMT) Received: from epsmgec5p1new.samsung.com (unknown [182.195.38.177]) by epsnrtp2.localdomain (Postfix) with ESMTP id 4VtbfN3yFfz4x9Pv; Tue, 4 Jun 2024 03:28:44 +0000 (GMT) Received: from epcas5p3.samsung.com ( [182.195.41.41]) by epsmgec5p1new.samsung.com (Symantec Messaging Gateway) with SMTP id 46.70.08853.CE98E566; Tue, 4 Jun 2024 12:28:44 +0900 (KST) Received: from epsmtrp1.samsung.com (unknown [182.195.40.13]) by epcas5p2.samsung.com (KnoxPortal) with ESMTPA id 20240603065101epcas5p2acde37ff1854ff6f455f51ec940caf65~Va_R6KOZ01423114231epcas5p2p; Mon, 3 Jun 2024 06:51:01 +0000 (GMT) Received: from epsmgmc1p1new.samsung.com (unknown [182.195.42.40]) by epsmtrp1.samsung.com (KnoxPortal) with ESMTP id 20240603065101epsmtrp18e7b805f6f3c250176196fb7d0105d49~Va_R3vysa1582915829epsmtrp1i; Mon, 3 Jun 2024 06:51:01 +0000 (GMT) X-AuditID: b6c32a44-fc3fa70000002295-08-665e89ec9f67 Received: from epsmtip1.samsung.com ( [182.195.34.30]) by epsmgmc1p1new.samsung.com (Symantec Messaging Gateway) with SMTP id B8.4E.07412.5D76D566; Mon, 3 Jun 2024 15:51:01 +0900 (KST) Received: from nj.shetty?samsung.com (unknown [107.99.41.245]) by epsmtip1.samsung.com (KnoxPortal) with ESMTPA id 20240603065058epsmtip19af2886049d9888391a19a98b3e4be4f~Va_OP59sS2735927359epsmtip1k; Mon, 3 Jun 2024 06:50:57 +0000 (GMT) Date: Mon, 3 Jun 2024 06:43:56 +0000 From: Nitesh Shetty To: Christoph Hellwig 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, 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 01/12] block: Introduce queue limits and sysfs for copy-offload support Message-ID: <20240603064356.nujnjbtje3vjnti2@nj.shetty@samsung.com> MIME-Version: 1.0 In-Reply-To: <20240601055323.GB5613@lst.de> X-Brightmail-Tracker: H4sIAAAAAAAAA02Te1BUVRzHO3fv3r1YS5eHcVgmh7nSFO9dWeDgiDVBdiebEXPGHHvACpdH 7Kt9aOAMgYiKBCvyilXj2RJgkkLyTmMFAsOdIEAQqCG2SCKIxqBBoIULjf99ft/ze//mkDxH k0BEJih1rEYpk9PENvym2dPT94/M92PFE2MuqK63i4dOXVjhodpxA4FmzAsAFc7/y0NTt88C tNxn4aGGrgmASsuv4GjkdjOG2sovYqi6thNDl4rSMdS5Nkugix1DAFkHjRhqH/VGZWcqcdTW 3oOjgZbLBCoxWQWoqnsVQ7nnBjHUNJUG0LWZORx9N+qGLCvd/FfcmIEf9zO95ZBpNo4LGMvE dZwZ6NMzN2oyCaa+8mNmur4YMK0jqQRTkZPHZ7LT/ySY5oyf+Mxf1lGcmftmkGByGmoA833p HUGE09HEPfGsLIbVuLPKaFVMgjIulN5/KDIsMjBILPGVhKBg2l0pU7ChdPibEb77EuS25dDu x2VyvU2KkGm1tP/ePRqVXse6x6u0ulCaVcfI1VK1n1am0OqVcX5KVrdbIhbvCrQ5RiXGD+Xm EOoml4+WUx+AVHDZ6TywIyElhYbGbOI82EY6Uq0Amq63YpyxYDNquvmc8Q+A5ol6sBUyXFDF 4x7aAVypz8U5428A+/v6BeteOOUBR0x9NiZJgvKGd9fIddmZoqH1Yd9GIh5VQMA1o9s6O1Ey WDXSvqELqTA435DK59gB9hRP4etsZ0tjqf4NrNeClNkOdt0twdfzQyocDjTSXHNO8GF3g4Bj EfzdcGaTT8Dq/C8ILvY0gMZh4+Y0L8OMXgOPaygeThuaN/XnYUHvNYzT7WH28hTG6ULY9NkW 74RX60oJjl3h0GLaJjPwktW8uccxANubR4gLYIfxiYGMT9TjeDfMnD/FN9rm4VFusGqV5NAT 1rX4lwJ+DXBl1VpFHBsdqJYo2RP/XzlapbgBNj6MV3gTuF+y6tcBMBJ0AEjyaGdhTso7sY7C GFlSMqtRRWr0clbbAQJt98nlibZHq2w/TqmLlEhDxNKgoCBpSECQhHYRzmRciXGk4mQ6NpFl 1axmKw4j7USpmNbhhaIM/x37rMdGH096e/RGer8OF6ZKBhZe1VdbzvmW2S+99O4PC4uxB1qy 8O3DFSaHR1SQ988+gcVzTsSXT0fLVvL1hx8veS2W+3j0BVTy3eSubrOFSQejzaFRDj4ftpc3 HFz61kQeD//1tChX+uCWpL86eWz6yNfBj5JffHb4lmtN8lMnG1Wiyp7X8kZO7m1+65muubiZ A8E6C23+tKzLPiSrRGLubCtO/4ScrZisXYHiqGBBRlpjvn/YB8OfKwwBR2OdQrRnj1Ue0jt/ 9UvKnY6hhTcUeT5Fh7N2Ls1O7up2vPreTUHpkdnkzKSU+jihIF5xr+i+6G2DOOBhoTx/vPbe czSujZdJvHgarew/c/aterkEAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa1BMYRzGveeczp5KzbGFN2vEYQyhbLm8bg3pwyG5fHC/rjptxm7lHJGI Te4Ry5A2tdmy22VEl2mkwoRSrGUS2lJkl6ZGchmTtGGL4dtvnmd+z//Ln8LF74gR1LaInRwf IVMwpBNRcpcZNaVevjFsaqraG12rrcLRwTM2HOW9Ok2ijrufAbrQ9R1HljtHAfphNOGouKoZ oAxdGoEa7pRiqFx3FkM5efcxlJqcgKH7Pz+Q6Gzlc4Cs9RoMVZgnoctHsghUXlFDoLqbl0ik 1VtFyFDdhyH1sXoM3bDEA5Tf8ZFAD8wSZLJVO8yXsHXPgthaHWRLNa9ErKm5gGDrjNFsYe5x ki3KOsC2FaUAtqxBRbKZSecc2FMJnSRberjFgf1kNRPsx1v1JJtUnAvYRxn3RMvd1jnNDeUU 23ZxvI//Fqfwruuv8ah295ib3V8IFWijTwBHCtLT4IvzBvwEcKLEdBmAVxKywUDhAfW2e/gA u8GcvvciO4vpTwDGl0XbmaDHwQa98XdOUSQ9CT78Sdljd5qB1nZj/wxOp5DwkVZpZzdaBg0N Ff25C70QdhWrHAbuNgNY01vypxgCa1IsxIA8A6YXvcHt+zgtgYa+/n3H36dMOe/BGUBr/jM0 /xmaf0YGwHOBBxclKOXKEGmUNILb7S3IlEJ0hNw7JFJZCPpfwWvCDdCs7fOuBBgFKgGkcMbd JWn/+jCxS6hsTyzHR27moxWcUAkkFMEMd5FeTA0V03LZTm47x0Vx/N8WoxxHqLAnr0s8Dab8 HYOFdml25ju3mF3hwTHg3OygC641TSPfjI50DnRfuSy4VzK0HDsd19p5e6Rv+u1GV7WlZ30h o57o17bEjxcWrs5sKpuXtT/3pbOGyWiM6clp8dN5JQtjtQFKcUpHYkCLdebe+Yf4VYpbBZvG zYzfNyNZsXzNrMTW2N6tcdN1vk+bwiaO7VmRPV5fsEXDLYBV5rql7f6iOSHINoyIm+ATaYv1 T0+bM+Zq59vjlpA8n1W+rtb8tEBPc+rswK/axsXTHq+t/abu3mw+/FxuuxLsMciTmTylep+q V7ge1prw42T2kw0feH2tsWqrYdHVtaODlN+htYlx7vYJiGMIIVwm9cJ5QfYLXINCcHkDAAA= X-CMS-MailID: 20240603065101epcas5p2acde37ff1854ff6f455f51ec940caf65 X-Msg-Generator: CA Content-Type: multipart/mixed; boundary="----Fualeei1.f5fhWGYL679EBd0hH5-OLgtfrOtH6wInDZGwDEe=_50408_" X-Sendblock-Type: REQ_APPROVE CMS-TYPE: 105P DLP-Filter: Pass X-CFilter-Loop: Reflected X-CMS-RootMailID: 20240520102830epcas5p27274901f3d0c2738c515709890b1dec4 References: <20240520102033.9361-1-nj.shetty@samsung.com> <20240520102033.9361-2-nj.shetty@samsung.com> <20240601055323.GB5613@lst.de> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240603_202854_575948_669E694D X-CRM114-Status: GOOD ( 25.53 ) X-BeenThere: linux-nvme@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-nvme" Errors-To: linux-nvme-bounces+linux-nvme=archiver.kernel.org@lists.infradead.org ------Fualeei1.f5fhWGYL679EBd0hH5-OLgtfrOtH6wInDZGwDEe=_50408_ Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Disposition: inline On 01/06/24 07:53AM, Christoph Hellwig wrote: >On Mon, May 20, 2024 at 03:50:14PM +0530, Nitesh Shetty wrote: >> Add device limits as sysfs entries, >> - copy_max_bytes (RW) >> - copy_max_hw_bytes (RO) >> >> Above limits help to split the copy payload in block layer. >> copy_max_bytes: maximum total length of copy in single payload. >> copy_max_hw_bytes: Reflects the device supported maximum limit. > >That's a bit of a weird way to phrase the commit log as the queue_limits >are the main thing (and there are three of them as required for the >scheme to work). The sysfs attributes really are just an artifact. > Acked, we will update commit log. >> @@ -231,10 +237,11 @@ int blk_set_default_limits(struct queue_limits *lim) >> { >> /* >> * Most defaults are set by capping the bounds in blk_validate_limits, >> - * but max_user_discard_sectors is special and needs an explicit >> - * initialization to the max value here. >> + * but max_user_discard_sectors and max_user_copy_sectors are special >> + * and needs an explicit initialization to the max value here. > >s/needs/need/ > Acked. >> +/* >> + * blk_queue_max_copy_hw_sectors - set max sectors for a single copy payload >> + * @q: the request queue for the device >> + * @max_copy_sectors: maximum number of sectors to copy >> + */ >> +void blk_queue_max_copy_hw_sectors(struct request_queue *q, >> + unsigned int max_copy_sectors) >> +{ >> + struct queue_limits *lim = &q->limits; >> + >> + if (max_copy_sectors > (BLK_COPY_MAX_BYTES >> SECTOR_SHIFT)) >> + max_copy_sectors = BLK_COPY_MAX_BYTES >> SECTOR_SHIFT; >> + >> + lim->max_copy_hw_sectors = max_copy_sectors; >> + lim->max_copy_sectors = >> + min(max_copy_sectors, lim->max_user_copy_sectors); >> +} >> +EXPORT_SYMBOL_GPL(blk_queue_max_copy_hw_sectors); > >Please don't add new blk_queue_* helpers, everything should go through >the atomic queue limits API now. Also capping the hardware limit >here looks odd. > This was a mistake, we are not using this function. We will remove this function in next version. >> + if (max_copy_bytes & (queue_logical_block_size(q) - 1)) >> + return -EINVAL; > >This should probably go into blk_validate_limits and just round down. > Bart also pointed out similar thing. We do same check before issuing copy offload, so we will remove this check. >Also most block limits are in kb. Not that I really know why we are >doing that, but is there a good reason to deviate from that scheme? > We followed discard as a reference, but we can move to kb, if that helps with overall readability. Thank you, Nitesh Shetty ------Fualeei1.f5fhWGYL679EBd0hH5-OLgtfrOtH6wInDZGwDEe=_50408_ Content-Type: text/plain; charset="utf-8" ------Fualeei1.f5fhWGYL679EBd0hH5-OLgtfrOtH6wInDZGwDEe=_50408_--