linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>,
	Kanchan Joshi <joshi.k@samsung.com>,
	Anuj Gupta <anuj20.g@samsung.com>,
	linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-nvme@lists.infradead.org
Subject: Re: fine-grained PI control
Date: Thu, 11 Jul 2024 07:42:24 +0200	[thread overview]
Message-ID: <20240711054224.GA4331@lst.de> (raw)
In-Reply-To: <yq1h6cy3r3f.fsf@ca-mkp.ca.oracle.com>

On Tue, Jul 09, 2024 at 11:47:58PM -0400, Martin K. Petersen wrote:
> For the user API I think it would be most sensible to have CHECK_GUARD,
> CHECK_APP, CHECK_REF to cover the common DIX/NVMe case.
> 
> And then we could have NO_CHECK_DISK and IP_CHECKSUM_CONVERSION to
> handle the peculiar SCSI corner cases and document that these are
> experimental flags to be used for test purposes only. Not particularly
> elegant but I don't have a better idea. Especially since things are
> inherently asymmetric with controller-to-target communication being
> protected even if you don't attach PI to the bio.
> 
> I.e. I think the CHECK_{GUARD,APP,REF} flags should describe how a
> DIX or NVMe controller should check the attached bip payload. And
> nothing else.

I really hate an API that is basically exposes a completely
different set of flags for SCSI vs NVMe.

I am also really not sold on IP_CHECKSUM_CONVERSION and the separate
no check for disk vs controller things.  I can see why someone would
want to do that for testing, but as a general API at the syscall
level it just is not a useful abstraction and highly confusing.

Can we figure out a way to do these as error injection points in
scsi or something similar so that we don't have to overload the
user interface with it?

> I'll try to connect my NVMe test box tomorrow. It's been offline after a
> rack move. Would like to understand what's going on. Are we not setting
> ILBRT/EILBRT appropriately?

I think NVMe just had a real mess with deallocation and Write Zeroes
in the past, and my test driver might be old enough to have implemented
the ECNs that fixes this eventually, assuming it actually got fixed
everywhere.


  reply	other threads:[~2024-07-11  5:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-05  8:32 fine-grained PI control Christoph Hellwig
2024-07-08 14:17 ` Anuj gupta
2024-07-09  7:08   ` Christoph Hellwig
2024-07-09  3:35 ` Martin K. Petersen
2024-07-09  7:16   ` Christoph Hellwig
2024-07-10  3:47     ` Martin K. Petersen
2024-07-11  5:42       ` Christoph Hellwig [this message]
2024-07-16  2:07         ` Martin K. Petersen
2024-07-26 10:21     ` Anuj Gupta
2024-07-29 17:03       ` Christoph Hellwig
     [not found]   ` <CGME20240918064651epcas5p418d61389752da25e5fc50e6a50a111b8@epcas5p4.samsung.com>
2024-09-18  6:39     ` Anuj Gupta
2024-09-24  1:59       ` Martin K. Petersen
2024-09-24  5:36         ` Christoph Hellwig
2024-09-27  2:01           ` Martin K. Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240711054224.GA4331@lst.de \
    --to=hch@lst.de \
    --cc=anuj20.g@samsung.com \
    --cc=joshi.k@samsung.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).