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

[FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>]

On Tue, 26 Jan 2010 11:20:43 -0500
Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:

> > 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?

Any tools with a system capable of fast I/Os like hundreds of SSDs?


> > 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.

I just want core functions to manage the swiotlb buffer (io_tlb)
there. Don't pass the address translation functions to swiotlb_map_*,
etc.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel