Messages in this thread | | | Subject | Re: Scheduled Transfer Protocol on Linux | Date | Sun, 13 Feb 2000 12:58:13 -0800 | From | Larry McVoy <> |
| |
: +----- : | The original proposal from Larry McVoy was to replace the electronics now : | inside a disk drive with an embedded general purpose processor. I'll repeat : +--->8 : : So? This differs from current SCSI drives only in degree, not in kind. If : the drive vendors felt the need to do it, I feel quite certain they could do : it, and in sufficient volume to make it competitive with high-end SCSI.
Exactly.
: | Imagine that cheapo IDIE drives could be bought soon with 100BaseT and : | not so soon with GigEth over copper connecters. They cost about $100 : | more than your current IDE drives (which are essentially free :-) : | : | Imagine Linux with STP in the kernel on _both_ ends of the connection. : +--->8 : : Right, "simple" NASD drives in a private SAN. This differs from SCSI : exactly how?
SCSI already runs layered on top of STP just fine, so to some extent it doesn't differ at all.
What it does do is give you a high bandwidth, low CPU cycle way of moving the data.
The simplified view of STP is really just remote DMA. How it works, again greatly simplified, is sort of like this:
client server request to send 1GB ->
<- please wait while I set up some pages (optional)
<- clear to send first 100MB of data, here's a cookie
data on wire, prefixed with incrementing cookie -> data on wire, prefixed with incrementing cookie -> data on wire, prefixed with incrementing cookie -> data on wire, prefixed with incrementing cookie -> data on wire, prefixed with incrementing cookie -> data on wire, prefixed with incrementing cookie -> data on wire, prefixed with incrementing cookie -> data on wire, prefixed with incrementing cookie -> data on wire, prefixed with incrementing cookie ->
-> data hits NIC, cockie is index into CAM, exactly like an ethernet switch indexes MAC addresses, except that the value here is a physical page address instead of an outgoing port
-> data hits NIC .... -> data hits NIC .... -> data hits NIC .... -> data hits NIC .... -> data hits NIC .... -> data hits NIC .... we're at 75MB or so server goes off and locks down another 100MB
<- CTS another 100MB (this happens well before the first 100MB is drained, so there are no bubbles, the pipe is 100% full at all times)
I trust that the SGI guys, who know this stuff better than I, will correct and problems with this description. I'm sure there are some, but I'm also sure this is pretty close to how it works modulo flow control, security, and other important bits.
What's important is that you notice two things:
(a) this is what I call "polite networking". Normal networking is impolite, the packets show up on your doorstep uninvited. Here, the receiver is nicely asked if it is OK, and gets to set things up first. Just like in DMA. (b) There is some hardware on the NIC that translates from packets to physical page addresses, this happens inline, so the packet gets DMAed into memory as it is coming off the wire. Very low buffering requirements.
So to get back to your question, SCSI is a fine protocol to layer on top of this. What STP is doing is giving you the illusion of large blocks in a fabric that has small packets. So if SCSI wants to do a 1MB transfer, it sees that over STP the same way it sees it over a local bus, as one big DMA.
It should be obvious that this is a huge win over traditional networking, right? If you want to go really fast, I don't know how else you can do it.
- 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/
| |