lkml.org 
[lkml]   [2000]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.087 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site