Re: [storm] iSER update request from Alex Nezhinsky on WSTAG

Mike Ko <Michael@huaweisymantec.com> Sat, 17 October 2009 00:56 UTC

MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_8KrsRxMGZlgkNUcPDsyNZQ)"
Message-id: <CBEA71A0755E4B3A9FF1FB12C1A5CD9B@china.huawei.com>
From: Mike Ko <Michael@huaweisymantec.com>
To: Black_David@emc.com, storm@ietf.org
References: <C6ADE32A02F740889CCBAA4392B5926C@china.huawei.com> <9FA859626025B64FBC2AF149D97C944A040BF6DE@CORPUSMX80A.corp.emc.com>
Date: Fri, 16 Oct 2009 17:56:33 -0700
Subject: Re: [storm] iSER update request from Alex Nezhinsky on WSTAG
Precedence: list

We could stipulate that if the response is "Not Understood", then the de facto implementation is the default.

Mike
  ----- Original Message ----- 
  From: Black_David@emc.com 
  To: Michael@huaweisymantec.com ; storm@ietf.org 
  Sent: Friday, October 16, 2009 5:44 PM
  Subject: RE: [storm] iSER update request from Alex Nezhinsky on WSTAG


  WG chair hat off:

  I think I understand what IB is doing, but what's the iWARP behavior?

  I'm concerned that introduction of a new key that has to be negotiated
  may break all the implementations that don't understand the new key.
  Thanks,
  --David






----------------------------------------------------------------------------
    From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Mike Ko
    Sent: Friday, August 21, 2009 12:43 AM
    To: STORM
    Subject: [storm] iSER update request from Alex Nezhinsky on WSTAG


    Alex sent me the following iSER update request:

    > WSTAG (RKEY+VA for IB) sent by the initiator with a WRITE SCSI
    > command de facto accounts for the offset, associated with the
    > solicited data, and does not reference the entire data. This happened
    > for historical reasons, but the actual "intuitive" rationale for that
    > is the fact that the initiator sometimes treats the memory regions
    > intended for unsolicited and solicited data transfers differently, as
    > they are carried out using different Infiniband mechanisms (Send from
    > the initiator, RDMA from the target) that imply different registration
    > modes. In contrast, the model implied by the iSER spec creators was
    > that the memory occupied by data is treated as contiguous (or
    > virtually contiguous, by means of scatter-gather mechanisms) and
    > homogenous region.
    >
    > Suggested solution; either change the spec to align it with the
    > de-facto implementations, or to add a flag to iSER-Hello message in
    > order to allow coping with the legacy implementations. Ironically,
    > iSER-Hello message currently is not implemented either, but we have to
    > assume that at some point in the future it will be universally
    > available.

    It seems to me there is also a third option other than the two outlined above.  That is, 
    create a new operational key that conveys how the memory region will be used.  This avoids having to require the use of iSER Hello messages if indeed that is not implemented in practise.

    Mike

[storm] iSER update request from Alex Nezhinsky o… Mike Ko
Re: [storm] iSER update request from Alex Nezhins… Black_David
Re: [storm] iSER update request from Alex Nezhins… Mike Ko