> Please don't add another 'layer' to the dma path. This leads to too
> many indirect function calls. Some people concern about the overhead
> of even the current code.
Any ideas on a good benchmarking tool for that?
>
> Create something like libswiotlb or whatever (as I said before) to
> export functions. Then call them directly.
I think what you suggesting is that that I abstract all of the address
translation functions ('phys_to_dma', 'bus_to_phys', etc.) from the swiotlb.c
layer.
Specifically, to altogether remove the phys_to_dma, bus_to_phys, etc. calls
from the swiotlb.c file. In place of them, have the results of those functions
(both physical and bus address) be passed in to the map_single and unmap_single
calls. The layer that calls map_single/unmap_single would then be responsible
for translating the phys/bus/virtual addresses.
Implementation wise, I could split the swiotlb.c in two files:
a) /lib/swiotlb-core.c and b) /lib/swiotlb-default.c.
The 'a)' would have the swiotlb_init_*, swiotlb_free, swiotlb_bounce,
sync_single, map_single, and unmap_single.
The 'b)' would contain the DMA function, such as swiotlb_sync_single_*,
swiotlb_[map|unmap]_[page|sg]_* and swiotlb_[alloc|free]_coherent.
Naturally it would do the phys,bus->bus,phys translations.
The Xen complementary to 'b)' would be in a different library/file
(/lib/swiotlb-xen.c?).
Is that close to what you were thinking?
>
> btw, please send swiotlb patches to lkml.
Once we've nailed down the structure of the changes I'll definitely
send it out to LKML.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home