Quoting r. Roland Dreier <[EMAIL PROTECTED]>: > Subject: Re: [PATCH 1/7] IB/core - Add DMA mapping functions to allow device > drivers to interpose > > > However, this means that the API must give the HCA the choice of > > what to keep inside the mapping. This could mean, for example, returning > > a structure that can include dma_addr_t, void*, or both, and a flag to > > distinguish between the two. > > It's an interesting idea. However I think it may be more trouble than it's > worth, for at least two reasons. First, the wrapper for dma_map_sg() will > probably become really ugly, although maybe there's a clever idea.
Oh, my guess is s/g is usually for long messages so we can just always do dma in that case. > Second, > the consumer right now only gets to pass a 64-bit address into the work > request posting functions. I don't think we really want to change that > interface, so the driver would have to encode the flag in the address somehow > anyway. But how? Wait, work request posting functions actually get a virtual address and a key, not a dma address. Maybe something can be done with this? Say, we have get_dma_mr at the moment - maybe we could have a special mr, and let the dma functions also select which mr to use? > Also handling highmem is a problem. ipath just depends on 64BIT so it > avoids the problem. I guess mthca could only return a kernel virtual > address if one exists, and always use DMA for highmem pages. So that > isn't really a serious objection. Right. -- MST _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
