Texas Instruments TMS320C645x manual Congestion Control, Detailed Description

www.ti.com

SRIO Functional Description

2.3.7Congestion Control

The RapidIO Flow Control specification is referenced in Table 1. This section describes the requirements and implementation of congestion control within the peripheral.

The peripheral is notified of switch fabric congestion through type 7 RapidIO packets. The packets are referred to as Congestion Control Packets (CCPs). The purpose of these packets is to turn off (Xoff), or turn on (Xon) specific flows defined by DESTID and PRIORITY of outgoing packets. CCPs are sent at the highest priority in an attempt to address fabric congestion as quickly as possible. CCPs do not have a response packet and they do not have guaranteed delivery.

When the peripheral receives an Xoff CCP, the peripheral must block outgoing LSU and CPPI packets that are destined for that flow. When the peripheral receives an Xon, the flow may be enabled. Since CCPs may arrive from different switches within the fabric, it is possible to receive multiple Xoff CCPs for the same flow. For this reason, the peripheral must maintain a table and count of Xoff CCPs for each flow. For example, if two Xoff CCPs are received for a given flow, two Xon CCPs must be received before the flow is enabled.

Since CCPs do not have guaranteed delivery and can be dropped by the fabric, an implicit method of enabling an Xoff’d flow must exist. A simple timeout method is used. Additionally, flow control checks can be enabled or disabled through the Transmit Source Flow Control Masks. Received CCPs are not passed through the DMA bus interface.

2.3.7.1Detailed Description

To avoid large and complex table management, a basic scheme is implemented for RIO congestion management. The primary goal is to avoid large parallel searches of a centralized congested route table for each outgoing packet request. The congested route table requirements and subsequent searches would be overwhelming if each possible DESTID and PRIORITY combination had its own entry. To implement a more basic scheme, the following assumptions have been made:

∙A small number of flows constitute the majority of traffic, and these flows are most likely to cause congestion

∙HOL blocking is undesired, but allowable for TX CPPI queues

∙Flow control will be based on DESTID only, regardless of PRIORITY

The congested route table is therefore more static in nature. Instead of dynamically updating a table with each CCP’s flow information as it arrives, a small finite-entry table is set up and configured by software to reflect the more critical flows it is using. Only these flows have a discrete table entry. A 16 entry table reflects 15 critical flows, leaving the sixteenth entry for general other flows, which are categorized together. Figure 27 shows the MMR table entries that are programmable by the CPU through the configuration bus. A 3-bit hardware counter is implemented for table entries 0 through 14, to maintain a count of Xoff CCPs for that flow. The other flows table entry counts Xoff CCPs for all flows other than the discrete entries. The counter for this table entry is 5-bit. All outgoing flows with non-zero Xoff counts are disabled. The counter value is decremented for each corresponding Xon CCP that is received, but it should not decrement below zero. Additionally, a hardware timer is needed for each table entry to turn on flows that may have been abandoned by lost Xon CCPs. The timer value needs to be an order of magnitude larger than the 32b Port Response Time-out CSR value. For this reason, each transmission source will add 2 bits to its 4-bit response time-out counter described in Section 2.3.3.3 and

Section 2.3.4.2. The additional 2 bits count three timecode revolutions and provide an implicit Xon timer equal to 3X the Response time-out counter value.

60 Serial RapidIO (SRIO) SPRU976 –March 2006

Submit Documentation Feedback