WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH 02/15] [swiotlb] Add swiotlb_engine structure for

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