[openib-general] [kDAPL]How to register a vmalloc() allocated buffer

[Ian Jiang]

My question originally come from the iSER. I  used to  think  that  a  data
buffer  described in a  iSCSI data PDU  is  in the user space, but now I am
afraid that it was not correct.


openib-general-bounces at openib.org wrote:
> > On Tue, Dec 06, 2005 at 08:52:13PM +0800, Ian Jiang wrote:
> >> Hi James,
> >> You are always so kind!
> >> Now I have a question about reading a buffer of a application in
> >> user space. Is it the only way to use the uDAPL?
> >> I used to have an idea like this:
> >> The application in user space gives the virtual start address and
> >> length of its data buffer to a kernel module program. This kernel
> >> program acts as a application of the kDAPL and registers the user
> >> space data buffer with the kDAPl,
> >
> > Ian,
> > If you are doing this with OpenIB, my advice is to NOT start
> > with kDAPL.
> > AFAICT, kDAPL is going away once any dependencies on it are resolved.
> > And it's clearly not going to be pushed to kernel.org source trees.
> > ISTR Dan Bar Dov wrote iSER was no longer dependent on kDAPL
> > but not sure if that was the only module.
> >
> >
> >> then request a RDMA read operation to complete the data transferring.
> >> But I think it is not feasible after getting your last reply. Am I
> >> right? Please give some suggestion and thanks very much!
> >
> > In general, a kernel module can map a user space address to a
> > "DMA Address". OpenIB code has interfaces to register the
> > "DMA Address" with the IB card.
> >
>
>
> kDAPL will still be of value for applications that want to minimize
> their dependencies on the OS while still operating in kernel space
> (but obviously not as part of *the* kernel).
>
> However, agenting user-mode buffers is going to get very OS
> specific, so this application doesn't seem to be one that
> would benefit from kDAPL.
>
>


--
Ian Jiang
ianjiang.ict at gmail.com

Laboratory of Spatial Information Technology
Division of System Architecture
Institute of Computing Technology
Chinese Academy of Sciences
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051207/e63753b5/attachment.html>