日韩精品超清视频一区,96无人区码一码二码三码

SPRUGR9H November 2010 – April 2015 66AK2E05 , 66AK2H06 , 66AK2H12 , 66AK2H14 , 66AK2L06 , AM5K2E02 , AM5K2E04 , SM320C6678-HIREL , TMS320C6652 , TMS320C6654 , TMS320C6655 , TMS320C6657 , TMS320C6670 , TMS320C6671 , TMS320C6672 , TMS320C6674 , TMS320C6678

4.3.2 Quality of Service Firmware

NOTE

The following paragraphs describe the original legacy Quality of Service (QoS) firmware. Refer to the Keystone media wiki for user guide documentation for the Scheduler and Drop Scheduler versions of QoS.

The quality of service (QoS) firmware has the job of policing all packet flows in the system, and verifying that neither the peripherals nor the host CPU are overwhelmed with packets.

The key to the functionality of the QoS system is the arrangement of packet queues. There are two sets of packet queues: the QoS ingress queues, and the final destination queues. The final destination queues are further divided into host queues and peripheral egress queues. Host queues are those that terminate on the host device and are actually received by the host. Egress queues are those that terminate at a physical egress peripheral device.

When shaping traffic, only the quality of service (QoS) PDSP writes to either the host queues or the egress queues. Unshaped traffic is written only to QoS ingress queues. It is the job of the QoS PDSP to move packets from the QoS ingress queues to their final destination queues while performing the proper traffic shaping in the process.

There is a designated set of queues in the system that feed into the QoS PDSP. These are called QoS queues. The QoS queues are simply queues that are controlled by the firmware running on the PDSP. There are no inherent properties of the queues that fix them to a specific purpose.

Egress queues are those that feed a physical egress peripheral or feed the host CPU. From the QoS PDSP's perspective, the final destination of any packet on a QoS queue is always an egress queue. Egress queues are referred to as peripheral egress queues when they feed a peripheral device, and host egress queues when they feed the host. The term peripheral egress queue is used more often here as this document typically assumes the QoS shaping is for transmit unless otherwise noted.

The egress queues keep track of the number of packets queued so that the QoS PDSP can get an idea of the egress devices' congestion level. Although there is no limit to the number of packets that can be placed on these queues, it is intended that they be kept shallow such that high priority packets can maintain a small latency period to their destination.

Operationally, the QoS firmware takes advantage of two Navigator features:

QM byte count/tracking feature. This feature is active when the application performs 64-bit pushes, writing a packet byte count to “Reg C” at the same time as writing the descriptor address (see Figure 4-13). The QoS firmware depends on this feature being used for QoS input queues.
Descriptor Return Qmgr, Return Qnum and Return Policy fields, normally used by the Tx PKTDMA to recycle descriptors. Only when dropping a packet will the QoS firmware read the descriptor. In this case it will obtain these values and push accordingly.

Programming the QoS firmware involves writing commands and records to the Command Interface (Scratch RAM) address of PDSPx. Table 4-53 shows the offsets for each of these items.

Table 4-53 QoS Firmware Memory Organization

Offset	Length	Field
0x0000	0x0040	Command Buffer
0x0040	0x01C0	QoS Cluster Records (8 records × 56 bytes each).
0x0200	0x0600	QoS Queue Records (64 records × 24 bytes each).
0x0C00	0x0020	SRIO Queue Monitoring Record (1 record x 32 bytes).