Hi Christoph! > One thing that I noticed is that for PI passed form userspace the > kernel never verifies that the guard and ref tag match what we'd > expect. Doing a verification pass in the write hot path had a substantial performance impact when I originally did this. Even remapping the ref tag has an impact on cache. That's why DIX1.1 moved ref tag remapping to the HBA so we could avoid touching the PI buffer altogether in the hot path. > I.e. if userspace passes incorrect information it can trigger a > command failure and thus the driver error handler, which is something > we don't usually allow for "regular" I/O. Do you trigger EH in NVMe? For SCSI we just bubble the PI error up without retrying. > Shouldn't the kernel do verification of the guard/ref tags on writes > with PI data? I'd prefer to have things fail gracefully if a problem is identified by the hardware. As opposed to adding a second CRC calculation pass to the hot path. > Also another thing is that right now the holder of a path or fd has no > idea what metadata it is supposed to pass. For block device special > files find the right sysfs directory is relatively straight forward > (but still annoying), but one a file is on a file systems that becomes > impossible. I think we'll need an ioctl that exposes the equivalent of > the integrity sysfs directory to make this usable by applications. I agree that poking around in sysfs and reading multiple files to combine all the various parameters is painful. Totally in favor of an ioctl to query the integrity format. -- Martin K. Petersen Oracle Linux Engineering
