[Xen-devel] Re: [PATCH 02/15] [swiotlb] Add swiotlb_engine structure for tracking multiple software IO TLBs.

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

> 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