Date: Thu, 24 Jul 1997 13:02:19 -0700 From: lamaster@george.arc.nasa.gov To: freebsd-smp@FreeBSD.ORG Subject: Re: Lots 'o PCI slots Message-ID: <199707242002.NAA24606@george.arc.nasa.gov>
next in thread | raw e-mail | index | archive | help
vanmaren@fast.cs.utah.edu (Kevin Van Maren) writes: > The I/O processor is off the PCI bus. In fact, Intel's i960 RP/RD > has two bridges integrated, which provides for a secondary PCI bus > with just one chip. Since the i960 is on the `other side' of the PCI > bus, I think it would be pretty stupid to have an x86-specific > multiprocessor support bus on the controller. However, it appears > that is exactly what they do: > http://134.134.214.1/design/iio/des.htm > which is annother reason Digital has their own I2O processor based on > the StrongARM. http://www.digital.com/info/semiconductor/press0303hm.htm When I first heard about the I2O processor, I thought maybe that it would be something like a Cray IOP, or at least an IBM channel. After I read through the online documentation, it sounds less interesting. As I read the docs, it sounds like it could help performance by fielding PCI interrupts for interrupt-crazy boards. That could be welcome news in some cases, but, since Unix/BSD folks tend to shy away from such boards anyway whenever possible, it seems that the only real "benefit" for well-behaved boards is going to be increased latency. For example, the most performance-critical path is usually the SCSI controller. If the controller already has a minimal-interrupt message-passing flavor, does gather-scatter, etc., what's the difference? Except for the added PCI bus traffic and the added latency due to the I/O request having to get processed in the I2O processor. What am I missing? > I don't think releasing technical info about the I2O spec is really > any different than not releasing info about a RAID controller or a > proprietary system bus. Many companies still want NDAs for their > hardware specs; this is just a `big company' that has lots of little If the reverse-engineering to document the interface takes place in Europe, and someone writes drivers based on the documented interface, it would appear that distribution of the resulting code would be legal, as long as no one violates an NDA. But, I'm not a lawyer and not giving legal advice. It could also be that there are some sneaky landmines hidden in the interface to make reverse-engineering more difficult, and to facilitate detection of NDA violations. > Shows the logical layout of the i960 RP. Note that cycles are NOT > allowed in the PCI spec; however, intel `fudged' this one by having > the i960 connected to both PCI busses: there are now two ways for > a message (data) to flow, which invalidates the consistency guarantees. > Of course, it is also broken with PCI 2.1's split transactions across > a bridge chip, as the requests aren't tagged. (A reads C, told to > `retry', bridge gets value from C, B reads C and bridge gives it to B > instead of C). HP did formal verification work to prove these > problems exist, although they have not publically released `fixes'. Presumably, the software will fix it so that either the CPU would own a particular device, or, the I2O processor would own the device, but, not both. In that case, is it still a problem? I'm not clear on how the I2O will prevent the CPU from seeing the PCI interrupts for the devices it owns, though, if they are sharing access to the same the PCI bus. Presumably, if the architecture ever migrates to the point where the I2O has direct access to system memory and has its own, multiple, PCI buses, then it would have much more of a benefit. Hugh LaMaster, M/S 258-5, ASCII Email: hlamaster@mail.arc.nasa.gov NASA Ames Research Center Or: lamaster@nas.nasa.gov Moffett Field, CA 94035-1000 No Junkmail: USC 18 section 2701 Phone: 415/604-1056 Disclaimer: Unofficial, personal *opinion*.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707242002.NAA24606>