Re: in-kernel verification of user PI?

[Christoph Hellwig <hch@lst.de>]

On Wed, Jan 29, 2025 at 11:15:35AM -0500, Martin K. Petersen wrote:
> 
> Christoph,
> 
> >> It fell by the wayside for various reasons. I would love to revive it,
> >> all it did was skip the remapping step if a flag was set in the profile.
> >
> > How much remapping could the hardware do?  Would this also work for
> > remapping a inode-relative ref tag?  Do we need to bring it into NVMe?
> 
> One of the reasons it lost momentum was that NVMe didn't do it for
> ILBRT/EILBRT. Although of course NVMe doesn't really have an
> intermediate HBA entity like SCSI.

Or any kind of coherent architecture for PI..

> With DIX1.1, you tell the HBA what to expect the first received ref tag
> to be. That could be the application's file offset or whatever you want.
> It's just the seed value chosen by the application when the PI was
> generated. That's passed down the stack along with the PI buffer itself.

Yeah.  NVMe actually kinda supports this, but for zone append only as we
need that for PI with zone append.   But it is limited to remapping from
a starting reftag that is the zone start address, so it's not quite as
flexibble.  Search for the PIREMAP bit in the ZNS spec.

> Not sure if we'd have room for both an EILBRT and an ILBRT in the same
> command? Sounds like it would be difficult, especially with the larger
> ref tags in NVMe. But I'm happy to pursue in NVMe if there is interest.
> Because it did make a performance difference not having to touch the PI
> buffer in the I/O path.

I guess you'd do it by treating type1 PI as actual type1 PI, that is
the ILBRT is derived from the LBA.  But I'd need to think more about
it, and without a clear customer use case it's probably not going to
happen in NVMe.