Re: [storm] Updated iSER draft

["Mallikarjun Chadalapaka" <[e-mail]>]

Hi Mike,

I hope you had a chance to see my note on this topic a few weeks ago.

>  5. Added two 64-bit fields in iSER header in section 9.2 for the Read
> Virtual Address and the Write Virtual Address to conform to the Infiniband
> format as proposed by Bob Russell.  This allows one implementation such as
> the OFED stack to be used in both the Infiniband and the iWARP
environment.

Are you proposing this protocol change to support just the OFED stack?

ZB-VA is supported with iWARP as a base feature, and I thought IB was going
to embrace it as an extension as of three years ago.  If that is the case,
IMO, we should reconsider making iSER protocol changes to support non-ZBVA
for benefiting one implementation - particularly when the change is neither
efficient nor free.  

Thanks.

Mallikarjun




> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
Mike
> Ko
> Sent: Friday, December 04, 2009 3:41 PM
> To: [e-mail]
> Subject: [storm] Updated iSER draft
> 
> I have just submitted an updated iSER draft to the storm WG.  The
following
> are extracted from section 14 on "Summary of Changes from RFC 5046":
> 
> 1. Removed the requirement that a connection be opened in "normal"     TCP
> mode and transitioned to zero-copy mode.  The allows the spec to conform
to
> existing implementation for both Infiniband and iWARP.  Changes were made
in
> sections 2, 3.1.6, 4.2, 5.1, 5.1.1, 5.1.2, 5.1.3, 10.1.3.4, and 11.
> 
> 2. Added a clause in section 6.2 to clarify that the initiator must not
send
> more than InitiatorMaxRecvDataSegmentLength worth of data when a NOP-Out
> request is sent with a valid Initiator Task Tag.  Since
> InitiatorMaxRecvDataSegmentLength can be smaller than
> TargetMaxRecvDataSegmentLength, returning the original data in the NOP-Out
> request in this situation can overflow the receive buffer unless the
length
> of the data sent with the NOP-Out request is less than
> InitiatorMaxRecvDataSegmentLength.
> 
> 3. Added MaxAHSLength key in section 6.8 to set a limit on the AHS Length
as
> proposed by Alex Nezhinsky.  This is useful when posting receive buffers
in
> knowing what the maximum possible message length is in a PDU which
contains
> AHS.
> 
> 4. Added WriteAddressForSolicitedDataOnly key in section 6.9 to indicate
how
> the memory region will be used as proposed by Alex Nezhinsky.  Alex argued
> that WSTAG (RKEY+VA for Infiniband) sent by the initiator with a WRITE
SCSI
> command already accounts for the offset associated with the solicited
data,
> and does not reference the entire data.  The rationale is that the
initiator
> sometimes treats the memory regions intended for unsolicited and solicited
> data 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.  Adding a new key will allow coping with current
> implementations.
> 
>  5. Added two 64-bit fields in iSER header in section 9.2 for the Read
> Virtual Address and the Write Virtual Address to conform to the Infiniband
> format as proposed by Bob Russell.  This allows one implementation such as
> the OFED stack to be used in both the Infiniband and the iWARP
environment.
> 
> Proposed Changes To Be Considered
> 
> 6. Alex Nezhinsky stated that iSER Hello and iSER HelloReply messages are
> not implemented in practice.  He argued that we should update the spec to
> remove the requirement to exchange the iSER Hello and iSER HelloReply
> messages.
> 
> Changes To Be Done
> 
> Update all diagrams to conform with the expanded iSER header format.
> 
> Mike
> 
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm