On Tue, Mar 07, 2000 at 02:44:36AM -0800, David S. Miller wrote:
> 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?
OK, that may have sounded selfish, but I'm not really in a position to
know how much or how little other hardware works the same way as mine
(where the device returns a 32-bit handle).
I'm quite prepared to accept that I would be the only driver writer to
benefit from an API change (in which case all this is moot) but I had
no easy way of knowing this - I posted to l-k for a bit of discussion.
I missed the original discussion of the DMA mapping things, does
anyone have a pointer to this?
> At this cost you receive portability and a clean API to work with.
> Also, you receive a lower driver maintenance cost, see below.
Portable, once the 32/64 bit issues are sorted out. Clean, I agree,
but write-only. The new API is good for anything with more than 4Gb of
RAM but imposes overhead (over the status quo) for everyone else.
[why reverse maps via page-tables are expensive]
OK, traipsing through tables is expensive. pci_unmap single does it -
the incremental cost of returning the original CPU pointer will not be
great (if it is possible at all). However, there are other ways of
performing reverse lookups (hash-tables, for example) in the face of
write-only (or close to write-only) hardware. I am not suggesting that
you stick in hash-tables, just thinking with my fingers.
> 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.
Ideas don't "go in", code does. I am not about to write a patch in the
face of your opposition. I think you exaggerate, it does not, for
example, look like bus_to_virt is going to last forever.
> 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.
I have a nice piece of hardware, that manages state (32-bit handle)
for me. It is just a shame that I will have to hack further state
tracking on top.
As it happens this is a Linux-only driver; I would imagine that the
majority of Linux (network) device drivers are as well.
> 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.
#include <write-only hardware moan>
Going off at a slight tangent... all the costs associated with mapping
and unmapping skbs become a lot smaller if the buffers can be recycled
in some fashion. Is there a proper (clean, documented) way of doing
this? The ATM devops interface provided a hook for this and may still
do so, but I don't know if it is safe.
Giuliano.
-- mail: gprocida@madge.com / myxie@debian.org | public PGP key ID: 93898735 home: +44 181 351 1172 / Flat 5, 135 Palmerston Road, London N22 8RW, UK work: +44 1753 661 305 / Madge Networks, Wexham Springs, Slough SL3 6PJ, UK- 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/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:22 EST