lkml.org 
[lkml]   [2000]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Scheduled Transfer Protocol on Linux
    Date
    From
    : +-----
    : | 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/

    \
     
     \ /
      Last update: 2005-03-22 13:56    [W:3.083 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site