> > This may be a nit, but IMO, the use of the term 'rkey' versus 'stag' > matters. They convey different ways of finding a data > buffer. For > > example, do you locate a buffer using the stag, then verify that the > offset + length fits into the target buffer? > > Yes. HW always uses the stag to locate a record that contains the stag > state (valid or invalid), the access flags, the 8b key, the > va_base, length, PBL describing the host pages, etc. HW validates all > that before using the buffer. NOTE: An stag of 0 is the > special local-dma-lkey which HW treats differently: If the stag is 0, then > the address in the SGE is the bus/dma address itself and > no lookup of a MR/PBL/etc is needed. Stag 0 can ONLY be used by kernel > users and MUST never be accepted/used from an ingress > packet and MUST never be emitted on the wire in a READ or WRITE. > > > Or do you locate the buffer > > by address, then verify that the key matches? > > > > This is never done. These were more rhetorical questions to highlight that stag is a better choice for the name than rkey. Lkey seems better than stag, though I'd rather see lkey removed completely. I don't see where usnic, ipath, qib, or opa technically need an lkey at all. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
