Re: Re: Invalidation

Caitlin Bestler <[email protected]>
Newsgroups gmane.ietf.rddp
Message-ID <[email protected]>
On Friday, October 3, 2003, at 07:07 PM, [email protected] wrote:

>> From reading your email, it sounds like you are thinking there is a
>> layering violation? Is that your point?
>
> No.  It appears that invalidation is a rather important mechanism
> for actually using STags, and so, aside from historical reasons, what's
> the rationale for it being an RDMAP operation rather than a DDP 
> operation?
>
> Another way to ask this is: does absence of STag invalidation from DDP
> significantly reduce the usefulness of DDP without RDMAP?  
> Alternatively,
> is invalidation sufficiently ULP (wrt DDP, e.g., RDMAP)-specific that
> it needs to be left to DDP's ULPs to implement and customize in their
> own fashion?
>
> If yes, the next question will be why it belongs in the RDMAP layer,
> as opposed to RDMAP providing local access to the DDP interface for
> STag invalidation, and letting ULPs figure out how to
> communicate STags when remote invalidation is in order.
>
> I don't have a preconceived notion of the answers, but there's some
> design rationale that needs to be brought out and discussed here.
>

As currently drafted, the DDP layer merely places the data from
valid DDP Segments, notes that the DDP Segment was placed,
and optionally notifies the next layer of completions.

STag invalidation must take place at or after completion
time, not at placement time. Therefore it would be awkward
to handle it within the DDP layer.

One of the justifications for the layering in my mind is
that it allows a very simple state machine to implement
the DDP layer, possibly leaving the RDMAP layer to a
more complex device (such as a processor).


Caitlin Bestler - [email protected] - http://asomi.com/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.