RE: [PATCH V3 1/5] RDMA/core: Transport-independent access flags

Hefty, Sean
2015-07-23T23:30:08Z

> > 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-rdma" in