Messages in this thread | | | Date | Tue, 7 Mar 2000 02:44:36 -0800 | From | "David S. Miller" <> | Subject | Re: DMA mapping |
| |
Date: Tue, 7 Mar 2000 09:56:16 +0000 From: Giuliano Procida <myxie@dev.madge.com>
I would hope I'm not too lazy, but I don't want to add unnecessary overhead to my code.
So your suggested solution is to add complexity to the core API instead?
My existing driver uses u32 handle = bus_to_virt(skb). There is no equivalent under the new DMA mapping scheme. Any change to the driver would involve more state handling (space and time costs) to all archs.
At this cost you receive portability and a clean API to work with. Also, you receive a lower driver maintenance cost, see below.
Making an inverse mapping function available would allow me to change to the new API without impacting the 32-bit ones.
Do not classify them as 32-bit ones, 32-bit cpu ports which can support >4GB of ram can make use of PCI controller page tables as well. Even x86 could take advantage of the AGP gart to allow DMA to physical memory >4GB (AMD Athlon systems have such a host bridge controller with this facility)
2. in the architectures (or current architectures in the future) where mapping actually does something, is handle = pci_map_single(address); address = pci_invertmap_single(handle) that I suggest above going to be cheaper or more expensive than the driver carrying extra state around?
Never. It will have to traverse page tables, and on some machines these page tables are in I/O space inside the PCI controller. Even if they are not in I/O space page tables, the main memory accesses to obtain the reverse mapping will be more expensive than if done via your driver state structure because unlike your driver state structure the cache lines containing the I/O page tables are constantly going back and forth between the PCI controller and the CPU. Ie. your driver state structure is likely to hit in the cpu caches, whereas the I/O page tables almost certainly will not.
If it would be much more expensive then I would ask for a #if define to made available so that I can conditionally include the extra state handling (or it might even be possible to do it generically and magically like spinlocks with respect to CONFIG_SMP).
No thanks. I'm not adding such complexity to the API, because then everyone will begin to use it and we will have to live with it forever. I have to stop ideas like this before they go in for this reason.
You need to keep track of this sort of information for just about every other portable driver API I am aware of, especially on Unix systems. So by doing things the way the current API requires you to you can share more code between your Linux and other-Unix versions. This is a decreased driver maintenance cost for you.
Let's consider also an architecture where the I/O page table interface is write and flush only, ie. you cannot get back a translation after you've fed it to the PCI controller. The current API happens to support that, and the sign of a good idea is when it solves problems which it never originally was meant to handle.
Later, David S. Miller davem@redhat.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |