Rules For Forwarding
A node will forward an incoming packet to its outbound link if any of the following conditions are met.
-
The packet is a broadcast request (determined from the command type)
-
The packet is a directed request which carries a UnitID = 0 (coming from a bridge), the compatibility bit is clear, and the address is not owned by this node.
-
The packet is a directed request which carries a UnitID = 0 (coming from a bridge), the compatibility bit is set, and this node is not the subtractive decoder or a bridge to it.
-
The packet is a response with the bridge bit set (traveling downstream from a bridge), and the UnitID field does not match that of the node.
-
The packet is a directed request which carries a non-zero UnitID (coming from an interior node). Non-bridges are not allowed to claim requests from interior nodes (no direct Peer-to-Peer transfers).
-
The packet is a response with the bridge bit clear (coming from an interior node). Non-bridges are not allowed to claim responses which are not sourced by a bridge (bridge bit must be set).
Other Notes On Forwarding
Forwarding Into The End Of Chain
An attempt to forward a packet into the end of a chain (device has EOC bit set) will result in a rejected packet. How the rejection is handled on the link is described in the next section on packet rejection. In addition, error handling policy programmed into the end-of-chain device determines what additional action should be taken (log error, generate an interrupt, etc.).
Forwarding If Initialization Is Not Complete
Another aspect of forwarding involves the behavior of a device which detects a packet that should be forwarded, but the device has not yet completed its initialization (EOC and Initialization Complete CSR bits still clear). Whether the incoming packet will be dropped or held pending initialization is then determined by the Drop on Uninitialized Link bit in the HyperTransport advanced capability Command Register.
No comments:
Post a Comment