[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: No Framing

    I share the concern about iSCSI embracing a framing mechanism that is
    not a MUST implement.  For all the reasons that Jim pointed out, OTOH,
    I am not recommending a MUST framing either.  I suspect not many will
    implement framing if it's a MAY, so it appears that we're talking about
    a potential SHOULD.
    Given that SHOULD is a fairly strong requirement, one "significant justification"
    for not doing framing could be (even while the NIC *may be* on the expensive side) -
     - has less design complexity since no OOO placement.
     - can have quicker TTM since less design, testing, debugging etc.
    I think ultimately it boils down to: how many vendors would use a "significant
    justfication" to not implement a SHOULD-requirement?
    If that's a majority: let's say vendor X is implementing (whatever) framing for
    optimizing the memory requirements, it essentially means that X's product will
    perform poorly with (the majority) no-framing senders.  I don't think X would
    like that, nor the customer.  IOW, this situation doesn't seem to be long-lasting.
    OTOH, the situation of an almost equal number of  "framing" and "no-framing"
    products in the market (perhaps at different price points) could be unfortunately
    To summarize, it is a troubling prospect that a framing technique (if adopted as
    SHOULD) has the potential to somewhat fracture the market and in effect
    create "interoperability problems" (of performance sort) similar to that affect
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    Hewlett-Packard MS 5668
    Roseville CA 95747
    > -----Original Message-----
    > From: WENDT,JIM (HP-Roseville,ex1) []
    > Sent: Tuesday, January 29, 2002 10:47 PM
    > To:
    > Subject: iSCSI: No Framing
    > So, it would be good to hear from several iSCSI
    > NIC/chip implementors who:
    > - have or plan to implement FIM or COWS (or some
    > other framing mechanism) and take advantage of it to
    > minimize demands on on-NIC buffer memory
    > bandwidth/quantity.
    > - believe that all-buffers-on-chip solutions are
    > feasible and valid (wrt the points above, including
    > #2)
    > - can quantify the memory/pin/power/space cost
    > savings for all-buffers-on-chip solutions
    > Jim


Last updated: Mon Feb 04 18:18:01 2002
8627 messages in chronological order