Subject: Re: [rddp] STag validation semantics

From: "Talpey, Thomas" <[email-masked]>
Date: Thu, 19 Sep 2002 18:49:02 -0400

At 12:35 PM 9/19/2002, Caitlin Bestler wrote:
>The first option will not work for DAFS, an STag can be
>delivered on the primary channel and used on the RDMA Read
>channel. Least effort ports of many existing protocols will
>similarly use multile streams and communicate STags that may
>be used on multiple streams within the sesssion.

I disagree - the mechanism by which an STag is delivered has
nothing to do with the scope of the STag's validity. And, DAFS
does not require its STags to have any particular scope - though
the STag used in an RDMA Read must of course be valid at
least on the DAFS RDMA Read channel of the session (or the
DAFS forward channel if the optional RDMA Read channel is
not bound in the session).

>My recomendation is that the method of interfacing be local, 
>or that we suggest something along the model of a InfiniBand 
>Protection Domain. It implements easily, already has 
>solutions and is capable of meeting application 
>requirements.

I agree with you that specifying the scope of the STag is not
a protocol issue, but a local policy. The PD is an excellent
approach to this.

Tom.

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

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 20 Sep 2002 07:07:17 -0500

> not bound in the session).

True, DAFS does not *require* that the same STag be valid on both
the forward and read channel. But consider what it would mean if
they were *not*:

-- The DAFS Provider would have to create a seperate STag for the
RDMA Read channel, and remember on each operation whether to encode
it or the STag for the forward channel in each request.

-- A sequence that read a record, modified it, and then wrote it
back would have to use different STags for the read and write even
though it was literally the same buffer being used.

-- The DAFS Provider will likely have been debugged for 
InfiniBand. There the same STag is valid for all channels within
a DAFS session because they all have the same Protection Domain.
Therefore this "mistake" will not be easily caught in advance.

-- There would be no way to take advantage of automatic invalidation
of the STag created for the RDMA Read channel, because there are
no SENDs performed on that channel,

The pattern will be the same for other multi-stream protocols.
It will be difficult and confusing to always determine what STag
is required to be used for each reference.

While this is a local interface I believe essential functionality
must be specified. In particular I think it is important that the
ULP be able to enable an STag on any set of streams. This is actually
stronger than what IB provides; IB has no mechanism for using the
same R-Key on different Protection Domains. This has the same
awkwardness problems as being forced to use different STags on
different streams, but at least it is far less likely to arise.

---

From: "Talpey, Thomas" <[email-masked]>
Date: Fri, 20 Sep 2002 10:49:44 -0400

>the forward and read channel. But consider what it would mean if

Absolutely - it is a highly useful capability for an application to be
able to specify the scope and also the attributes of its STags. For
instance in your examples, being able to create a readable as well as
writable STag is of course expected, and using it on commonly
authenticated channels is desired. But, no protocol exposure is
required. These attributes are a local issue and in fact *shouldn't*
be visible on the wire. They are handled by local facilities.

Tom.