[EMAIL PROTECTED] wrote: > On 3/21/06, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote: >> Quoting Fabian Tillier <[EMAIL PROTECTED]>: >>> I'd still be interested in seeing regular registration calls >>> improved, as it's clear that an application that is sensitive about >>> its security must either restrict itself to send/recv, buffer the >>> data (data copy overhead), or register/unregister for each I/O. >> >> I guess regular registration calls could be improved, but the >> benefit is not all that obvious. >> >> Which applications do register/unregister for each I/O? > > I think if register/unregister wasn't so painfully slow, a > lot more applications would do it. It's the most secure, and > unlike memory windows, supports scatter gather. > > There was enough people who wanted to register on the fly > that Mellanox invented their FMR implementation - regular > registration wasn't cutting it. Otherwise, why would there be a need > for it? > > The problem with the mthca FMRs is that they're still > insecure, on par with the full frontal DMA MR from a security > standpoint. Anyone worried about security is stuck with good > old regular registration, or memory windows. > > - Fab
the point of a memory window is that it is an alias for a slice of memory that is already registered, subsetting by address range and/or access permissions. As such the subsetting request can be taken in an unsecure work request on the fast path directly from a non-privileged user. Since they are only creating an alias for a subset of the access rights already established there is no need for involvement of a privileged agent -- hence it can be lightweight. Memory registration will *always* cost more, because it MUST involve a privileged intermediary who can vouch for ownership of the registered memory. And all applications *should* worry about memory, and the API needs to support those applications with reasonable options -- those include memory windows and FMR work requests. Forcing applications to chose between painful memory registration and security is a dead-end that must be avoided. _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general