Subject: RE: [rddp] Re: Invalidation

From: "Jim Pinkerton" <[email-masked]>
Date: Wed, 1 Oct 2003 20:42:27 -0700

David,

>From reading your email, it sounds like you are thinking there is a
layering violation? Is that your point?

If so, I'd claim otherwise. Clearly there is an interface above DDP to
enable a buffer to be mapped to an STag, and just as clearly there is an
interface to invalidate that mapping. Thus to me all that is happening
is RDMAP, as the ULP to DDP, is calling the invalidate mechanism for a
DDP STag.

On Caitlin's points below, I agree with the Quirk summary, and also
agree that we should make it clear that the local peer can choose to
configure an STag to never be invalidated (regardless of whether an
invalidate STag is received). This is effectively a DOS attack otherwise
(and I'll add it to the security draft).

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Caitlin Bestler
> Sent: Tuesday, September 30, 2003 8:14 AM
> To: [email-masked]
> Cc: David Black
> Subject: [rddp] Re: Invalidation
> 
> 
> On Monday, September 29, 2003, at 02:12 PM, [email-masked] wrote:
> 
> > (2) Invalidation.  We have a lingering issue from way back
> > 	when that RDMAP is handling invalidation of STags,
> > 	which are DDP level resources.  This needs some
> > 	serious examination in this forum.
> 
> I'm not sure I remember anything that qualifies as an
> "issue". There are certainly some quirks that relate to
> the fact that the invalidation is inherently asynchronous
> because it is processed on the "completion track" and at
> least theoretically by a different layer (and hence potentially
> as well).
> 
> Quirk #1: Invalidation is not a fence. "Later" DDP Segments
> may be placed prior to the invalidation -- even if received
> in order. Invalidation offers no guarantees to the sender,
> only to the receiver. And the receiver is only guaranteed
> that there will be no further placements *when the notice
> of the invalidation is delivered*. The only guarantee about
> what was placed at that point is that *earlier* DDP segments
> will have been placed. There is no guarantee that *later*
> DDP segments were *not* placed.
> 
> Quirk #2: Invalidation may or may not disrupt an in-process
> RDMA Read. That is, there is no specification on *when* an
> RDMA Read engine translates STags.
> 
> 
> 
> The last issue is that the current wording does not allow
> a local implementation to suppress remote invalidation on
> specific tags. This essentially prevents exporting STags
> that are associated with permanent data structures such
> as Memory Regions (as opposed to windows). That should be
> fixed.
> 
> In general, remote invalidation should not be viewed as
> providing any guarantees to the remote side. It is a
> service to the local ULP. While it ought to remain
> mandatory to implement, the local ULP should have
> the option of not using it for a specific STag.
> 
> 
> 
> _______________________________________________
> rddp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rddp

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