Subject: RE: [rddp] Stream Inititation (8.1)

From: "Renato Recio" <[email-masked]>
Date: Fri, 4 Oct 2002 11:08:35 -0500

Julian,
   Option #2 seems like good informative text to place in an appendix.

Renato J Recio
Distinguished Engineer
IBM I/O Architecture and Technology
Tel 512-838-3685, T/L 678-3685

                      "Julian Satran"                                                                                   
                      <Julian_Satran@il        To:       Renato Recio/Austin/IBM@IBMUS                                  
                      .ibm.com>                cc:       [email-masked], [email-masked]                             
                      Sent by:                 Subject:  RE: [rddp] Stream Inititation (8.1)                            
                      [email-masked]                                                                                 
                      rg                                                                                                

                      10/04/2002 10:07                                                                                  
                      AM                                                                                                

As this will affect interoperability you have either:
   1. provide a detailed sequence for any ULP
   2. provide a template and let the ULP fill-in-the-blanks

I guess that 2 would be more beneficial to the community and might help
insure that the generic hardware has the right level of support for the
local exchanges.

Julo

    Renato Recio/Austin/IBM@IBMUS                                          
    Sent by: [email-masked]            To:        [email-masked]       
                                            cc:                            
                                            Subject:        RE: [rddp]     
    30/09/02 19:21                  Stream Inititation (8.1)               

Caitlin,

In my view, the first paragraph of section 8.1 of the RDMA specification is
sufficient.  Specifically the second and third sentences:  "The ULP is
responsible for transitioning the LLP Stream into RDMA enabled mode. Once
in RDMA enabled mode, an implementation MUST send only RDMA Messages across
the transport Stream until the RDMAP Stream is torn down."

In my view, the second sentence covers your point.  In other words, if the
passive side ULP wants to wait for the active side to send an RDMA Message
it can do so.  On the otherhand, if the active/passive side immediately
start off in RDMA mode, the passive side can immediately start sending RDMA
Messages.

BTW, I created a presentation during the development of the .95 draft that
outlines a set of connection establishment options that are possible for
RDMAP.  I tried posting it to this reflector, but the e-mail was too long.
If you are interested in it,  let me know and I'll be happy to send it to
you.

Thanks,

Renato J Recio
Distinguished Engineer
IBM I/O Architecture and Technology
Tel 512-838-3685, T/L 678-3685

                     Caitlin Bestler

                     <[email-masked]        To:       [email-masked]

                     i.net>                   cc:       Michael Krause
<[email-masked]>
                     Sent by:                 Subject:  RE: [rddp] Stream
Inititation (8.1)
                     [email-masked]

                     rg

                     09/30/2002 10:56

                     AM

On 9/30/02, Michael Krause wrote:

>
>I do not see any change proposed for the RDMA / DDP / MPA
>specs in the below exchange.  Given there are no wire
>protocol changes proposed, then aside from an
>implementation education for ULP, it appears this is a
>non-issue from a specification perspective.
>

You are correct that there is no required change to any of
the wire protocol.

However, both the ddp and rdma drafts place requirements on
the local interface: specifically that the ULP can enter
RDMA mode at any any time after the stream is connected
(especially immediately).

As pointed out in the prior posts, this local interface is
inadequate. It either requires the ULPs to engage in timing
to avoid race conditions, or to have a complex interface
between the RDMA stack and traditional stack.

Based upon Paul Culley's refinement of my suggestion, it is
clear that the *only* refinements to the local interface are
as follows:

1) The ULP may enable RDMA send and RDMA receive modes
seperately.

2) The ULP may *fence* the first RDMA send pending receipt
of the first RDMA message. (So that the passive side can be
assured that the active side has completed enabling RDMA).

That is the *only* specification change required, and it
only deals with the very minimal "verb" description in
section 8.1.

I would argue that this very minor increase in the
reuqirements for the local interface is preferable to ULP
negotiations that have inherent race conditions in them
and/or complex "delivery revocation" interfaces with
software L2-up stacks.

It is also necessary that these capabilities be specified in
the draft. Later ULPs cannot define their own application
specific peer-to-peer unless the local interface
capabilities they rely upon are documented in the base
standard. There is no need to specify an API, or even a
verb, just that this capability is available to the ULP.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp