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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BB759C32771 for ; Wed, 21 Sep 2022 09:27:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231548AbiIUJ1X (ORCPT ); Wed, 21 Sep 2022 05:27:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46632 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231416AbiIUJ1S (ORCPT ); Wed, 21 Sep 2022 05:27:18 -0400 Received: from mta-01.yadro.com (mta-02.yadro.com [89.207.88.252]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1EC1F8E0F1; Wed, 21 Sep 2022 02:27:17 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-01.yadro.com (Postfix) with ESMTP id 9AE1941252; Wed, 21 Sep 2022 09:27:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yadro.com; h= in-reply-to:content-transfer-encoding:content-disposition :content-type:content-type:mime-version:references:message-id :subject:subject:from:from:date:date:received:received:received :received; s=mta-01; t=1663752434; x=1665566835; bh=Zo8hxc7svqb4 BFaKV7Mv5NTNkTTzcrDesurD+cIxjTE=; b=XbnMHwzikvvrwMVzaW637TKfaflG tNgDyhAR7ITQjJWiyszQatfFDWEnfr1ljpTMNZmapG8DWIB/s1yPDtHCKcxvRqsm WFCXn9qIVfObg0KWQKRlZt+nC5QGeHU5uXEhPMVqtrIwHBEHANnUqTbWcIbka6Yf +Gj3uI81xQsJLVw= X-Virus-Scanned: amavisd-new at yadro.com Received: from mta-01.yadro.com ([127.0.0.1]) by localhost (mta-01.yadro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8-Aiz6fb9MR; Wed, 21 Sep 2022 12:27:14 +0300 (MSK) Received: from T-EXCH-02.corp.yadro.com (T-EXCH-02.corp.yadro.com [172.17.10.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mta-01.yadro.com (Postfix) with ESMTPS id 2B11F41263; Wed, 21 Sep 2022 12:26:12 +0300 (MSK) Received: from T-EXCH-09.corp.yadro.com (172.17.11.59) by T-EXCH-02.corp.yadro.com (172.17.10.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Wed, 21 Sep 2022 12:26:12 +0300 Received: from yadro.com (10.199.18.119) by T-EXCH-09.corp.yadro.com (172.17.11.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.1118.9; Wed, 21 Sep 2022 12:26:11 +0300 Date: Wed, 21 Sep 2022 12:26:09 +0300 From: "Alexander V. Buev" To: Keith Busch CC: , , Jens Axboe , Christoph Hellwig , "Martin K . Petersen" , Pavel Begunkov , Chaitanya Kulkarni , Mikhail Malygin , Subject: Re: [PATCH v5 0/3] implement direct IO with integrity Message-ID: <20220921092609.m4duniwc6jmfrort@yadro.com> Mail-Followup-To: "Alexander V. Buev" , Keith Busch , linux-block@vger.kernel.org, io-uring@vger.kernel.org, Jens Axboe , Christoph Hellwig , "Martin K . Petersen" , Pavel Begunkov , Chaitanya Kulkarni , Mikhail Malygin , linux@yadro.com References: <20220920144618.1111138-1-a.buev@yadro.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Originating-IP: [10.199.18.119] X-ClientProxiedBy: T-EXCH-01.corp.yadro.com (172.17.10.101) To T-EXCH-09.corp.yadro.com (172.17.11.59) Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org > «Внимание! Данное письмо от внешнего адресата!» > > On Tue, Sep 20, 2022 at 05:46:15PM +0300, Alexander V. Buev wrote: > > This series of patches makes possible to do direct block IO > > with integrity payload using io uring kernel interface. > > Userspace app can utilize new READV_PI/WRITEV_PI operation with a new > > fields in sqe struct (pi_addr/pi_len) to provide iovec's with > > integrity data. > > Is this really intended to be used exclusively for PI? Once you give use space > access to extended metadata regions, they can use it for whatever the user > wants, which may not be related to protection information formats. Perhaps a > more generic suffix than "_PI" may be appropriate like _EXT or _META? Currently we use this code for transfer block IO with meta information from user space to special block device driver. This meta information includes PI and some other information that helps driver to process IO with some optimization, special option and etc. In the near feature we can extend this info die to increased requirements for our product. Also we can use this code for transfer IO with PI information from user space to supported block devices such as nvme & scsi. And you are right. Just for me "_meta" is more appropriate and abstract suffix for this, but: 1. "PI" is shortly 2. "PI" and "integrity" is widely used in block layer code and I decided that if it's called PI - everyone understands what exactly it is about. 3. User can read/write general info only in case of using special block layer driver. Anyway I'm ready to rename this things. May be it's enough to rename only userspace visible part? (sqe struct members & op codes) -- Alexander V. Buev