On Fri, 3 Nov 2006, Michael S. Tsirkin wrote:
> 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. Work requests posted using ib_post_send/recv are specified using a dma address obtained using the appropriate Linux DMA mapping API function. They are not virtual addresses. > 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 > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
