Re: [storm] Updated iSER draft

[Mike Ko <[e-mail]>]

Mallikarjun,

The question is whether our intention to update the iSER spec is to reflect 
"running code".  This hinges on whether there are any other commonly adopted 
software support for iSER other than the OFED stack.  Felix Marti responded 
in November that the Chelsio iWARP products support ZBVA, but no detail was 
given on how this is done.  Do you know of any "running code" in widespread 
use that supports ZBVA?

Unless there are some recent changes, AFAIK, there is no intention of 
embracing ZBVA in IB.  ZBVA is "tolerated" because it is in the iSER spec.

Mike
----- Original Message ----- 
From: "Mallikarjun Chadalapaka" <[e-mail]>
To: "'Mike Ko'" <[e-mail]>; <[e-mail]>
Sent: Friday, December 04, 2009 4:19 PM
Subject: RE: [storm] Updated iSER draft


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