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
