Download
1 / 7
70 likes | 86 Views
The Stats Engine is a critical component designed for accepting messages in a scratch ring and executing operations to manage counters effectively. With support for atomic increment and add operations, this single ME is dedicated to updating counters used by various MEs. Specific opcodes dictate the format of commands for operations such as incrementing and adding data to counters based on pre- or post-queue specifications. The Stats Engine manages Stats Counters and Stats Registers to ensure accurate tracking of packet and byte counts across different categories. It implements priority levels for counters stored in local memory or SRAM, offering optimized performance based on the type of events being monitored. This reliable system empowers plug-ins to redefine counter usage without altering opcodes and includes detailed allocation strategies for registers.
E N D
ONL Stats Engine David M. ZarApplied Research LaboratoryComputer Science and Engineering Department
Opcode(4b) Data (12b) Index (16b) Stats Engine • The Stats Engine will be a single ME devoted to accepting messages in a scratch ring and performing increment and add operations to counters. • All MEs that need to update counters will use the Stats Engine • Operations supported will be • Atomic increment (+1) • Atomic add (+data) • Format of the commands will be
Opcode(4b) Data (12b) Index (16b) Opcodes • Opcode – • 0011 +1, +data pre-q counter specified in Index • 0111 +1, +data post-q counter specified in Index • 0010 +1 pre-q counter specified in Index • 0110 +1 post-q counter specified in Index • 0001 +data pre-q counter specified in Index • 0101 +data post-q counter specified in Index • 1011 +1, +data register specified in Index • 1010 +1 register specified in Index
Stats Counters • Each Index specifies a group of four counters • Pre-Q packet count • Pre-Q byte count • Post-Q packet count • Post-Q byte count • The packet counters get updated when the +1 instructions are specified (opcodes 0-1-) • The byte counter get updated when the +data instructions are specified (opcodes 0--1) • For plug-ins, the use for each counter can be redefined but the opcodes do not change (i.e. each stats index corresponds to two incrementers and two adders).
Stats Registers • For system-wide counters, we define a separate set of registers to handle them. • RX (packet and byte, 5 ports 10 words) • TX (packet and byte, 5 ports 10 words) • Drop counts (10 words) • Plug-in use (four per plug-in 20 words) • 10+10+10+20 = 50 so reserve 64 words for these • The register gets incremented when the +1 instructions are specified (opcodes 101-) • The register gets added to updated when the +data instructions are specified (opcodes 10-1) • The RX and TX counters will be assigned on even-word boundaries (lsb = 0) so we associate the packet and byte coutners, together, and can do the +1, +data instruction on them in one command • For plug-ins, the allocation of each register is under the control of the plug-in.
Stats Counter Priority • There are two levels of priority for Stats Counters • High-priority (high-speed) are kept in local memory. There are 64 sets of counters for the router and 64 for the plug-ins • Low-priority (low-speed) are in SRAM. There are 216-128 = 65408 of these. • Stats Counters 0-127 point to the high-priority counters while 128-65535 are low-priority counters. • Using low-priority Stats Counters to count events that happen at high speed may degrade system performance (being a pre-Q counter on a high-priority queue, for example) • Plug-ins need to be aware of the segmentation of priority so they can use the proper priority counters based on needs • Stats Registers are always high-priority • One ME thread will be used to write 8W chunks of the local memory counters/registers to SRAM so that each counter/register is updated in SRAM several times a second.
