This is what we are doing in ISER (creating the QP in kernel as the connect action of a socket provider that is accessed by userspace).
Dan On 12/8/05, Caitlin Bestler <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > Hi, > > > > What are the reasons that a qp allocated in user-space can't > > be passed and used by a kernel module? > > What are the steps needed to make a userspace-allocated qp usable by > > a kernel module? > > > > > > You would need to construct an environment such that the > device-specific verbs module, which assumes it is executing > in the user space where the QP was created, would never notice > the difference. > > The device-specific verbs will typically have created shared > memory resources that are accessible by both the RDMA device > and from the creating user memory map. These resources may > include pointers that assume the original memory map. The > exact methods of remembering the locations of these resources > will vary by device, so the chance of coming up with a scheme > that works without explicit support of all device vendors is > very low. The chances of convincing all device vendors to add > a new option to support this model is similarly low unless you > can make a very compelling case as to why this is necessary. > > Having the in-kernel proxy create the QP and do operations > for the end-user is a very adequate work around. > > For complex cleanup purposes the kernel could simply assume > the identity of the failed process, but that would only be > required if the standard cleanup was somehow not adequate. > > _______________________________________________ > openib-general mailing list > [email protected] > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
