Re: [Gems-users] About ordered virtual networks


Date: Thu, 6 Dec 2007 10:57:53 -0600
From: "Mike Marty" <mike.marty@xxxxxxxxx>
Subject: Re: [Gems-users] About ordered virtual networks



when I declare a virtual network as "ordered" in my SLICC protocol, does
this imply that the destination node receives the messages in the same
sequence the sender issues them, doesn't matter the physical path they
follow? (I mean: is it an end-to-end ordering, or just a
switch-to-switch ordering - as some actual implementations of this
mechanism ensure? The latter case implies that the path is important).

Declaring the virtual network as "ordered" implies point-to-point ordering.  That is, if P1 sends messages {A, B} to P2, then P2 will receive them in that order.  It does not imply any total ordering of the interconnect. 

This essentially turns off adaptive routing for that virtual network and enables an assertion in MessageBuffer that prevents you from enqueuing two messages where the latter has a latency delay that would make it go before the first message


Another question: some implementations of the coherence protocols
released with GEMS (my version is 1.4) have an ordered "Forward Network"
(this is the case of SMP protocols, for example the
MOSI_SMP_directory_1level), but other protocols use an unordered
"Forward Network" (this is the case of CMP protocols, for example
MOESI_CMP_directory). Is there a particular reason for this, or it is
just a protocol-dependent characteristic?

A protocol dependent characteristic.  Having an ordered Forward network eliminates en entire class of races.  The HP/Compaq GS320 directory protocol uses an ordered forward network

--Mike

[← Prev in Thread] Current Thread [Next in Thread→]