fine-grained PI control

[Martin K. Petersen]

Christoph,

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

I don't disagree.

It is unfortunate that PI in NVMe was defined at a time when PCIe was
the only transport and therefore it didn't make sense to have a
distinction between controller and target. In our experience there is a
lot of value in being able to identify where exactly the corruption
happened, we use it all the time.

In an ideal world we'd be able to have multiple orthogonal protection
envelopes as envisioned in the SNIA efforts. But with NVMe only
supporting one envelope and the SCSI host-target envelope being wonky, I
sadly don't see that happening.

That said, I don't particularly like the idea of removing existing
functionality to match whichever subset of PI/DIX/AMDI that NVMe decided
to adopt.

I am OK in principle with the idea of the user API only describing the
first envelope as long as I have a different way of controlling the
second envelope on a per-I/O basis. It is fine to require this use case
to be explicitly configured and enabled. Many PI devices require
configuration prior to testing anyway.

> 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'm experimenting with a few different approaches...

-- 
Martin K. Petersen	Oracle Linux Engineering