lkml.org 
[lkml]   [1999]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Ideas for abstracting driver IO from bus implementation?
On Wed, Mar 17, 1999 at 05:01:38AM +0000, Alan Cox wrote:
> > My thought is to have a socket driver publish a set of entry points
> > for primitive IO operations: effectively, replacements for readw,
> > writew, inb, outb, and friends. These would be passed out to any
>
> Ok so you replace a 1 clock pairable operation with 3 or 4 memory operations
> a call, and a pipeline stall.
>
> That tells me its not general purpose 8)

It depends on what you want from a "general purpose" solution. It is
general enough that you can support devices that can't be supported in
the current make-everything-look-like-a-PC framework. And general
enough that Sun uses it for all drivers on all platforms (not that I'm
terribly happy with their implementation). It is not general enough
to provide absolute maximum performance.

However, the cost is not as bad as you imply. As far as I know, any
uncached memory transaction is going to have a latency of >10 cycles,
and perhaps much more, though write buffers will hide some of this.
So in most cases, the time to actually do the IO is going to dominate.
And I don't see the pipeline stall: the PII can predict and prefetch
across indirect branches, and for the simple case of a driver talking
to target(s) with just one bus primitive, the branch predictions
should be 100% accurate.

> To give you an example why this matters in many cases - my I2O code paths
> are (last time I checked the asm)
>
> 2 instructions to get a simple message
> 14 instructions to build a typical message
> 1 instruction to post it
>
> So it takes me 17 clocks to tell the controller to do something. If you
> wrapped the read/write's it would probably double it

I don't know that much about I2O, but it seems like the impact of the
wrapper layer would depend on the relative amount of work that gets
done per I2O message. If a wrapper adds a couple dozen clocks to a
message that causes the transfer of a network packet or disk sector,
then it would be much less intrusive than if the transfer time of
every byte were increased.

Anyhow, I don't think the IO abstraction layer would need to be used
for all drivers, and it probably wouldn't ever be used for something
like I2O. I see it being used mainly in unusual situations where
specific hardware constraints (independent of performance) make it
impossible to use the native bus abstractions for certain devices.

> Macros I would guess are the right answer if you can encode a bus/port
> pair into 32bits. Then you can rebuild any driver with

I thought about doing something like this, but coming up with a
general coding scheme for putting the bus info in the address seems
tricky to me. I guess I can just pretend that the device is mapped
into the normal IO space (and allocate a range of addresses as if it
is, as a placeholder), but then the macro for inb() would need to
reverse the mapping, which would be messy.

-- Dave Hinds

-
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:50    [W:0.181 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site