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

From: <[email-masked]>
Date: Fri, 16 Oct 2009 20:44:26 -0400

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: [email-masked] [mailto:[email-masked]] 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

---

From: Mike Ko <[email-masked]>
Date: Fri, 16 Oct 2009 17:56:33 -0700

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

Mike
  ----- Original Message ----- 
  From: [email-masked] 
  To: [email-masked] ; [email-masked] 
  Sent: Friday, October 16, 2009 5:44 PM
  Subject: RE: [storm] iSER update request from Alex Nezhinsky on WSTAG

  WG chair hat off:

----------------------------------------------------------------------------
    From: [email-masked] [mailto:[email-masked]] 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:

    > 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
    > 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

    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