Messages in this thread | | | Date | Wed, 17 Mar 1999 15:26:28 -0800 | From | David Hinds <> | Subject | Re: 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/
| |