diff options
Diffstat (limited to '')
| -rw-r--r-- | tools/perf/pmu-events/arch/x86/jaketown/uncore-interconnect.json | 824 |
1 files changed, 813 insertions, 11 deletions
diff --git a/tools/perf/pmu-events/arch/x86/jaketown/uncore-interconnect.json b/tools/perf/pmu-events/arch/x86/jaketown/uncore-interconnect.json index 1b53c0e609e3..750870fd1cb1 100644 --- a/tools/perf/pmu-events/arch/x86/jaketown/uncore-interconnect.json +++ b/tools/perf/pmu-events/arch/x86/jaketown/uncore-interconnect.json @@ -1,48 +1,850 @@ [ { - "BriefDescription": "QPI clock ticks. Used to get percentages of QPI cycles events", + "BriefDescription": "Number of qfclks", "Counter": "0,1,2,3", "EventCode": "0x14", "EventName": "UNC_Q_CLOCKTICKS", "PerPkg": "1", + "PublicDescription": "Counts the number of clocks in the QPI LL. This clock runs at 1/8th the 'GT/s' speed of the QPI link. For example, a 8GT/s link will have qfclk or 1GHz. JKT does not support dynamic link speeds, so this frequency is fixed.", "Unit": "QPI LL" }, { - "BriefDescription": "Cycles where receiving QPI link is in half-width mode", + "BriefDescription": "Count of CTO Events", + "Counter": "0,1,2,3", + "EventCode": "0x38", + "EventName": "UNC_Q_CTO_COUNT", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of CTO (cluster trigger outs) events that were asserted across the two slots. If both slots trigger in a given cycle, the event will increment by 2. You can use edge detect to count the number of cases when both events triggered.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Direct 2 Core Spawning; Spawn Failure - Egress Credits", + "Counter": "0,1,2,3", + "EventCode": "0x13", + "EventName": "UNC_Q_DIRECT2CORE.FAILURE_CREDITS", + "PerPkg": "1", + "PublicDescription": "Counts the number of DRS packets that we attempted to do direct2core on. There are 4 mutually exlusive filters. Filter [0] can be used to get successful spawns, while [1:3] provide the different failure cases. Note that this does not count packets that are not candidates for Direct2Core. The only candidates for Direct2Core are DRS packets destined for Cbos.", + "UMask": "0x2", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Direct 2 Core Spawning; Spawn Failure - Egress and RBT", + "Counter": "0,1,2,3", + "EventCode": "0x13", + "EventName": "UNC_Q_DIRECT2CORE.FAILURE_CREDITS_RBT", + "PerPkg": "1", + "PublicDescription": "Counts the number of DRS packets that we attempted to do direct2core on. There are 4 mutually exlusive filters. Filter [0] can be used to get successful spawns, while [1:3] provide the different failure cases. Note that this does not count packets that are not candidates for Direct2Core. The only candidates for Direct2Core are DRS packets destined for Cbos.", + "UMask": "0x8", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Direct 2 Core Spawning; Spawn Failure - RBT Not Set", + "Counter": "0,1,2,3", + "EventCode": "0x13", + "EventName": "UNC_Q_DIRECT2CORE.FAILURE_RBT", + "PerPkg": "1", + "PublicDescription": "Counts the number of DRS packets that we attempted to do direct2core on. There are 4 mutually exlusive filters. Filter [0] can be used to get successful spawns, while [1:3] provide the different failure cases. Note that this does not count packets that are not candidates for Direct2Core. The only candidates for Direct2Core are DRS packets destined for Cbos.", + "UMask": "0x4", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Direct 2 Core Spawning; Spawn Success", + "Counter": "0,1,2,3", + "EventCode": "0x13", + "EventName": "UNC_Q_DIRECT2CORE.SUCCESS", + "PerPkg": "1", + "PublicDescription": "Counts the number of DRS packets that we attempted to do direct2core on. There are 4 mutually exlusive filters. Filter [0] can be used to get successful spawns, while [1:3] provide the different failure cases. Note that this does not count packets that are not candidates for Direct2Core. The only candidates for Direct2Core are DRS packets destined for Cbos.", + "UMask": "0x1", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Cycles in L1", + "Counter": "0,1,2,3", + "EventCode": "0x12", + "EventName": "UNC_Q_L1_POWER_CYCLES", + "PerPkg": "1", + "PublicDescription": "Number of QPI qfclk cycles spent in L1 power mode. L1 is a mode that totally shuts down a QPI link. Use edge detect to count the number of instances when the QPI link entered L1. Link power states are per link and per direction, so for example the Tx direction could be in one state while Rx was in another. Because L1 totally shuts down the link, it takes a good amount of time to exit this mode.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Cycles in L0p", "Counter": "0,1,2,3", "EventCode": "0x10", "EventName": "UNC_Q_RxL0P_POWER_CYCLES", - "MetricExpr": "(UNC_Q_RxL0P_POWER_CYCLES / UNC_Q_CLOCKTICKS) * 100.", - "MetricName": "rxl0p_power_cycles %", "PerPkg": "1", + "PublicDescription": "Number of QPI qfclk cycles spent in L0p power mode. L0p is a mode where we disable 1/2 of the QPI lanes, decreasing our bandwidth in order to save power. It increases snoop and data transfer latencies and decreases overall bandwidth. This mode can be very useful in NUMA optimized workloads that largely only utilize QPI for snoops and their responses. Use edge detect to count the number of instances when the QPI link entered L0p. Link power states are per link and per direction, so for example the Tx direction could be in one state while Rx was in another.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Cycles in L0", + "Counter": "0,1,2,3", + "EventCode": "0xf", + "EventName": "UNC_Q_RxL0_POWER_CYCLES", + "PerPkg": "1", + "PublicDescription": "Number of QPI qfclk cycles spent in L0 power mode in the Link Layer. L0 is the default mode which provides the highest performance with the most power. Use edge detect to count the number of instances that the link entered L0. Link power states are per link and per direction, so for example the Tx direction could be in one state while Rx was in another. The phy layer sometimes leaves L0 for training, which will not be captured by this event.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Rx Flit Buffer Bypassed", + "Counter": "0,1,2,3", + "EventCode": "0x9", + "EventName": "UNC_Q_RxL_BYPASSED", + "PerPkg": "1", + "PublicDescription": "Counts the number of times that an incoming flit was able to bypass the flit buffer and pass directly across the BGF and into the Egress. This is a latency optimization, and should generally be the common case. If this value is less than the number of flits transfered, it implies that there was queueing getting onto the ring, and thus the transactions saw higher latency.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "CRC Errors Detected; LinkInit", + "Counter": "0,1,2,3", + "EventCode": "0x3", + "EventName": "UNC_Q_RxL_CRC_ERRORS.LINK_INIT", + "PerPkg": "1", + "PublicDescription": "Number of CRC errors detected in the QPI Agent. Each QPI flit incorporates 8 bits of CRC for error detection. This counts the number of flits where the CRC was able to detect an error. After an error has been detected, the QPI agent will send a request to the transmitting socket to resend the flit (as well as any flits that came after it).", + "UMask": "0x1", + "Unit": "QPI LL" + }, + { + "BriefDescription": "CRC Errors Detected; Normal Operations", + "Counter": "0,1,2,3", + "EventCode": "0x3", + "EventName": "UNC_Q_RxL_CRC_ERRORS.NORMAL_OP", + "PerPkg": "1", + "PublicDescription": "Number of CRC errors detected in the QPI Agent. Each QPI flit incorporates 8 bits of CRC for error detection. This counts the number of flits where the CRC was able to detect an error. After an error has been detected, the QPI agent will send a request to the transmitting socket to resend the flit (as well as any flits that came after it).", + "UMask": "0x2", + "Unit": "QPI LL" + }, + { + "BriefDescription": "VN0 Credit Consumed; DRS", + "Counter": "0,1,2,3", + "EventCode": "0x1e", + "EventName": "UNC_Q_RxL_CREDITS_CONSUMED_VN0.DRS", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of times that an RxQ VN0 credit was consumed (i.e. message uses a VN0 credit for the Rx Buffer). This includes packets that went through the RxQ and those that were bypasssed.", + "UMask": "0x1", + "Unit": "QPI LL" + }, + { + "BriefDescription": "VN0 Credit Consumed; HOM", + "Counter": "0,1,2,3", + "EventCode": "0x1e", + "EventName": "UNC_Q_RxL_CREDITS_CONSUMED_VN0.HOM", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of times that an RxQ VN0 credit was consumed (i.e. message uses a VN0 credit for the Rx Buffer). This includes packets that went through the RxQ and those that were bypasssed.", + "UMask": "0x8", + "Unit": "QPI LL" + }, + { + "BriefDescription": "VN0 Credit Consumed; NCB", + "Counter": "0,1,2,3", + "EventCode": "0x1e", + "EventName": "UNC_Q_RxL_CREDITS_CONSUMED_VN0.NCB", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of times that an RxQ VN0 credit was consumed (i.e. message uses a VN0 credit for the Rx Buffer). This includes packets that went through the RxQ and those that were bypasssed.", + "UMask": "0x2", + "Unit": "QPI LL" + }, + { + "BriefDescription": "VN0 Credit Consumed; NCS", + "Counter": "0,1,2,3", + "EventCode": "0x1e", + "EventName": "UNC_Q_RxL_CREDITS_CONSUMED_VN0.NCS", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of times that an RxQ VN0 credit was consumed (i.e. message uses a VN0 credit for the Rx Buffer). This includes packets that went through the RxQ and those that were bypasssed.", + "UMask": "0x4", + "Unit": "QPI LL" + }, + { + "BriefDescription": "VN0 Credit Consumed; NDR", + "Counter": "0,1,2,3", + "EventCode": "0x1e", + "EventName": "UNC_Q_RxL_CREDITS_CONSUMED_VN0.NDR", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of times that an RxQ VN0 credit was consumed (i.e. message uses a VN0 credit for the Rx Buffer). This includes packets that went through the RxQ and those that were bypasssed.", + "UMask": "0x20", + "Unit": "QPI LL" + }, + { + "BriefDescription": "VN0 Credit Consumed; SNP", + "Counter": "0,1,2,3", + "EventCode": "0x1e", + "EventName": "UNC_Q_RxL_CREDITS_CONSUMED_VN0.SNP", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of times that an RxQ VN0 credit was consumed (i.e. message uses a VN0 credit for the Rx Buffer). This includes packets that went through the RxQ and those that were bypasssed.", + "UMask": "0x10", + "Unit": "QPI LL" + }, + { + "BriefDescription": "VNA Credit Consumed", + "Counter": "0,1,2,3", + "EventCode": "0x1d", + "EventName": "UNC_Q_RxL_CREDITS_CONSUMED_VNA", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of times that an RxQ VNA credit was consumed (i.e. message uses a VNA credit for the Rx Buffer). This includes packets that went through the RxQ and those that were bypasssed.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "RxQ Cycles Not Empty", + "Counter": "0,1,2,3", + "EventCode": "0xa", + "EventName": "UNC_Q_RxL_CYCLES_NE", + "PerPkg": "1", + "PublicDescription": "Counts the number of cycles that the QPI RxQ was not empty. Generally, when data is transmitted across QPI, it will bypass the RxQ and pass directly to the ring interface. If things back up getting transmitted onto the ring, however, it may need to allocate into this buffer, thus increasing the latency. This event can be used in conjunction with the Flit Buffer Occupancy Accumulator event to calculate the average occupancy.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Received - Group 0; Data Tx Flits", + "Counter": "0,1,2,3", + "EventCode": "0x1", + "EventName": "UNC_Q_RxL_FLITS_G0.DATA", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits received from the QPI Link. It includes filters for Idle, protocol, and Data Flits. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time (for L0) or 4B instead of 8B for L0p.", + "UMask": "0x2", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Received - Group 0; Idle and Null Flits", + "Counter": "0,1,2,3", + "EventCode": "0x1", + "EventName": "UNC_Q_RxL_FLITS_G0.IDLE", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits received from the QPI Link. It includes filters for Idle, protocol, and Data Flits. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time (for L0) or 4B instead of 8B for L0p.", + "UMask": "0x1", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Received - Group 0; Non-Data protocol Tx Flits", + "Counter": "0,1,2,3", + "EventCode": "0x1", + "EventName": "UNC_Q_RxL_FLITS_G0.NON_DATA", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits received from the QPI Link. It includes filters for Idle, protocol, and Data Flits. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time (for L0) or 4B instead of 8B for L0p.", + "UMask": "0x4", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Received - Group 1; DRS Flits (both Header and Data)", + "Counter": "0,1,2,3", + "EventCode": "0x2", + "EventName": "UNC_Q_RxL_FLITS_G1.DRS", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x18", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Received - Group 1; DRS Data Flits", + "Counter": "0,1,2,3", + "EventCode": "0x2", + "EventName": "UNC_Q_RxL_FLITS_G1.DRS_DATA", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x8", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Received - Group 1; DRS Header Flits", + "Counter": "0,1,2,3", + "EventCode": "0x2", + "EventName": "UNC_Q_RxL_FLITS_G1.DRS_NONDATA", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x10", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Received - Group 1; HOM Flits", + "Counter": "0,1,2,3", + "EventCode": "0x2", + "EventName": "UNC_Q_RxL_FLITS_G1.HOM", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x6", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Received - Group 1; HOM Non-Request Flits", + "Counter": "0,1,2,3", + "EventCode": "0x2", + "EventName": "UNC_Q_RxL_FLITS_G1.HOM_NONREQ", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x4", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Received - Group 1; HOM Request Flits", + "Counter": "0,1,2,3", + "EventCode": "0x2", + "EventName": "UNC_Q_RxL_FLITS_G1.HOM_REQ", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x2", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Received - Group 1; SNP Flits", + "Counter": "0,1,2,3", + "EventCode": "0x2", + "EventName": "UNC_Q_RxL_FLITS_G1.SNP", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x1", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Received - Group 2; Non-Coherent Rx Flits", + "Counter": "0,1,2,3", + "EventCode": "0x3", + "EventName": "UNC_Q_RxL_FLITS_G2.NCB", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for NDR, NCB, and NCS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0xc", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Received - Group 2; Non-Coherent data Rx Flits", + "Counter": "0,1,2,3", + "EventCode": "0x3", + "EventName": "UNC_Q_RxL_FLITS_G2.NCB_DATA", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for NDR, NCB, and NCS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x4", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Received - Group 2; Non-Coherent non-data Rx Flits", + "Counter": "0,1,2,3", + "EventCode": "0x3", + "EventName": "UNC_Q_RxL_FLITS_G2.NCB_NONDATA", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for NDR, NCB, and NCS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x8", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Received - Group 2; Non-Coherent standard Rx Flits", + "Counter": "0,1,2,3", + "EventCode": "0x3", + "EventName": "UNC_Q_RxL_FLITS_G2.NCS", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for NDR, NCB, and NCS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x10", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Received - Group 2; Non-Data Response Rx Flits - AD", + "Counter": "0,1,2,3", + "EventCode": "0x3", + "EventName": "UNC_Q_RxL_FLITS_G2.NDR_AD", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for NDR, NCB, and NCS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x1", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Received - Group 2; Non-Data Response Rx Flits - AK", + "Counter": "0,1,2,3", + "EventCode": "0x3", + "EventName": "UNC_Q_RxL_FLITS_G2.NDR_AK", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for NDR, NCB, and NCS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x2", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Rx Flit Buffer Allocations", + "Counter": "0,1,2,3", + "EventCode": "0x8", + "EventName": "UNC_Q_RxL_INSERTS", + "PerPkg": "1", + "PublicDescription": "Number of allocations into the QPI Rx Flit Buffer. Generally, when data is transmitted across QPI, it will bypass the RxQ and pass directly to the ring interface. If things back up getting transmitted onto the ring, however, it may need to allocate into this buffer, thus increasing the latency. This event can be used in conjunction with the Flit Buffer Occupancy event in order to calculate the average flit buffer lifetime.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Rx Flit Buffer Allocations - DRS", + "Counter": "0,1,2,3", + "EventCode": "0x9", + "EventName": "UNC_Q_RxL_INSERTS_DRS", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Number of allocations into the QPI Rx Flit Buffer. Generally, when data is transmitted across QPI, it will bypass the RxQ and pass directly to the ring interface. If things back up getting transmitted onto the ring, however, it may need to allocate into this buffer, thus increasing the latency. This event can be used in conjunction with the Flit Buffer Occupancy event in order to calculate the average flit buffer lifetime. This monitors only DRS flits.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Rx Flit Buffer Allocations - HOM", + "Counter": "0,1,2,3", + "EventCode": "0xc", + "EventName": "UNC_Q_RxL_INSERTS_HOM", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Number of allocations into the QPI Rx Flit Buffer. Generally, when data is transmitted across QPI, it will bypass the RxQ and pass directly to the ring interface. If things back up getting transmitted onto the ring, however, it may need to allocate into this buffer, thus increasing the latency. This event can be used in conjunction with the Flit Buffer Occupancy event in order to calculate the average flit buffer lifetime. This monitors only HOM flits.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Rx Flit Buffer Allocations - NCB", + "Counter": "0,1,2,3", + "EventCode": "0xa", + "EventName": "UNC_Q_RxL_INSERTS_NCB", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Number of allocations into the QPI Rx Flit Buffer. Generally, when data is transmitted across QPI, it will bypass the RxQ and pass directly to the ring interface. If things back up getting transmitted onto the ring, however, it may need to allocate into this buffer, thus increasing the latency. This event can be used in conjunction with the Flit Buffer Occupancy event in order to calculate the average flit buffer lifetime. This monitors only NCB flits.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Rx Flit Buffer Allocations - NCS", + "Counter": "0,1,2,3", + "EventCode": "0xb", + "EventName": "UNC_Q_RxL_INSERTS_NCS", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Number of allocations into the QPI Rx Flit Buffer. Generally, when data is transmitted across QPI, it will bypass the RxQ and pass directly to the ring interface. If things back up getting transmitted onto the ring, however, it may need to allocate into this buffer, thus increasing the latency. This event can be used in conjunction with the Flit Buffer Occupancy event in order to calculate the average flit buffer lifetime. This monitors only NCS flits.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Rx Flit Buffer Allocations - NDR", + "Counter": "0,1,2,3", + "EventCode": "0xe", + "EventName": "UNC_Q_RxL_INSERTS_NDR", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Number of allocations into the QPI Rx Flit Buffer. Generally, when data is transmitted across QPI, it will bypass the RxQ and pass directly to the ring interface. If things back up getting transmitted onto the ring, however, it may need to allocate into this buffer, thus increasing the latency. This event can be used in conjunction with the Flit Buffer Occupancy event in order to calculate the average flit buffer lifetime. This monitors only NDR flits.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Rx Flit Buffer Allocations - SNP", + "Counter": "0,1,2,3", + "EventCode": "0xd", + "EventName": "UNC_Q_RxL_INSERTS_SNP", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Number of allocations into the QPI Rx Flit Buffer. Generally, when data is transmitted across QPI, it will bypass the RxQ and pass directly to the ring interface. If things back up getting transmitted onto the ring, however, it may need to allocate into this buffer, thus increasing the latency. This event can be used in conjunction with the Flit Buffer Occupancy event in order to calculate the average flit buffer lifetime. This monitors only SNP flits.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "RxQ Occupancy - All Packets", + "Counter": "0,1,2,3", + "EventCode": "0xb", + "EventName": "UNC_Q_RxL_OCCUPANCY", + "PerPkg": "1", + "PublicDescription": "Accumulates the number of elements in the QPI RxQ in each cycle. Generally, when data is transmitted across QPI, it will bypass the RxQ and pass directly to the ring interface. If things back up getting transmitted onto the ring, however, it may need to allocate into this buffer, thus increasing the latency. This event can be used in conjunction with the Flit Buffer Not Empty event to calculate average occupancy, or with the Flit Buffer Allocations event to track average lifetime.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "RxQ Occupancy - DRS", + "Counter": "0,1,2,3", + "EventCode": "0x15", + "EventName": "UNC_Q_RxL_OCCUPANCY_DRS", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Accumulates the number of elements in the QPI RxQ in each cycle. Generally, when data is transmitted across QPI, it will bypass the RxQ and pass directly to the ring interface. If things back up getting transmitted onto the ring, however, it may need to allocate into this buffer, thus increasing the latency. This event can be used in conjunction with the Flit Buffer Not Empty event to calculate average occupancy, or with the Flit Buffer Allocations event to track average lifetime. This monitors DRS flits only.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "RxQ Occupancy - HOM", + "Counter": "0,1,2,3", + "EventCode": "0x18", + "EventName": "UNC_Q_RxL_OCCUPANCY_HOM", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Accumulates the number of elements in the QPI RxQ in each cycle. Generally, when data is transmitted across QPI, it will bypass the RxQ and pass directly to the ring interface. If things back up getting transmitted onto the ring, however, it may need to allocate into this buffer, thus increasing the latency. This event can be used in conjunction with the Flit Buffer Not Empty event to calculate average occupancy, or with the Flit Buffer Allocations event to track average lifetime. This monitors HOM flits only.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "RxQ Occupancy - NCB", + "Counter": "0,1,2,3", + "EventCode": "0x16", + "EventName": "UNC_Q_RxL_OCCUPANCY_NCB", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Accumulates the number of elements in the QPI RxQ in each cycle. Generally, when data is transmitted across QPI, it will bypass the RxQ and pass directly to the ring interface. If things back up getting transmitted onto the ring, however, it may need to allocate into this buffer, thus increasing the latency. This event can be used in conjunction with the Flit Buffer Not Empty event to calculate average occupancy, or with the Flit Buffer Allocations event to track average lifetime. This monitors NCB flits only.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "RxQ Occupancy - NCS", + "Counter": "0,1,2,3", + "EventCode": "0x17", + "EventName": "UNC_Q_RxL_OCCUPANCY_NCS", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Accumulates the number of elements in the QPI RxQ in each cycle. Generally, when data is transmitted across QPI, it will bypass the RxQ and pass directly to the ring interface. If things back up getting transmitted onto the ring, however, it may need to allocate into this buffer, thus increasing the latency. This event can be used in conjunction with the Flit Buffer Not Empty event to calculate average occupancy, or with the Flit Buffer Allocations event to track average lifetime. This monitors NCS flits only.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "RxQ Occupancy - NDR", + "Counter": "0,1,2,3", + "EventCode": "0x1a", + "EventName": "UNC_Q_RxL_OCCUPANCY_NDR", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Accumulates the number of elements in the QPI RxQ in each cycle. Generally, when data is transmitted across QPI, it will bypass the RxQ and pass directly to the ring interface. If things back up getting transmitted onto the ring, however, it may need to allocate into this buffer, thus increasing the latency. This event can be used in conjunction with the Flit Buffer Not Empty event to calculate average occupancy, or with the Flit Buffer Allocations event to track average lifetime. This monitors NDR flits only.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "RxQ Occupancy - SNP", + "Counter": "0,1,2,3", + "EventCode": "0x19", + "EventName": "UNC_Q_RxL_OCCUPANCY_SNP", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Accumulates the number of elements in the QPI RxQ in each cycle. Generally, when data is transmitted across QPI, it will bypass the RxQ and pass directly to the ring interface. If things back up getting transmitted onto the ring, however, it may need to allocate into this buffer, thus increasing the latency. This event can be used in conjunction with the Flit Buffer Not Empty event to calculate average occupancy, or with the Flit Buffer Allocations event to track average lifetime. This monitors SNP flits only.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Stalls Sending to R3QPI; BGF Stall - HOM", + "Counter": "0,1,2,3", + "EventCode": "0x35", + "EventName": "UNC_Q_RxL_STALLS.BGF_DRS", + "PerPkg": "1", + "PublicDescription": "Number of stalls trying to send to R3QPI.", + "UMask": "0x1", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Stalls Sending to R3QPI; BGF Stall - DRS", + "Counter": "0,1,2,3", + "EventCode": "0x35", + "EventName": "UNC_Q_RxL_STALLS.BGF_HOM", + "PerPkg": "1", + "PublicDescription": "Number of stalls trying to send to R3QPI.", + "UMask": "0x8", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Stalls Sending to R3QPI; BGF Stall - SNP", + "Counter": "0,1,2,3", + "EventCode": "0x35", + "EventName": "UNC_Q_RxL_STALLS.BGF_NCB", + "PerPkg": "1", + "PublicDescription": "Number of stalls trying to send to R3QPI.", + "UMask": "0x2", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Stalls Sending to R3QPI; BGF Stall - NDR", + "Counter": "0,1,2,3", + "EventCode": "0x35", + "EventName": "UNC_Q_RxL_STALLS.BGF_NCS", + "PerPkg": "1", + "PublicDescription": "Number of stalls trying to send to R3QPI.", + "UMask": "0x4", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Stalls Sending to R3QPI; BGF Stall - NCS", + "Counter": "0,1,2,3", + "EventCode": "0x35", + "EventName": "UNC_Q_RxL_STALLS.BGF_NDR", + "PerPkg": "1", + "PublicDescription": "Number of stalls trying to send to R3QPI.", + "UMask": "0x20", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Stalls Sending to R3QPI; BGF Stall - NCB", + "Counter": "0,1,2,3", + "EventCode": "0x35", + "EventName": "UNC_Q_RxL_STALLS.BGF_SNP", + "PerPkg": "1", + "PublicDescription": "Number of stalls trying to send to R3QPI.", + "UMask": "0x10", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Stalls Sending to R3QPI; Egress Credits", + "Counter": "0,1,2,3", + "EventCode": "0x35", + "EventName": "UNC_Q_RxL_STALLS.EGRESS_CREDITS", + "PerPkg": "1", + "PublicDescription": "Number of stalls trying to send to R3QPI.", + "UMask": "0x40", "Unit": "QPI LL" }, { - "BriefDescription": "Cycles where transmitting QPI link is in half-width mode", + "BriefDescription": "Stalls Sending to R3QPI; GV", + "Counter": "0,1,2,3", + "EventCode": "0x35", + "EventName": "UNC_Q_RxL_STALLS.GV", + "PerPkg": "1", + "PublicDescription": "Number of stalls trying to send to R3QPI.", + "UMask": "0x80", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Cycles in L0p", "Counter": "0,1,2,3", "EventCode": "0xd", "EventName": "UNC_Q_TxL0P_POWER_CYCLES", - "MetricExpr": "(UNC_Q_TxL0P_POWER_CYCLES / UNC_Q_CLOCKTICKS) * 100.", - "MetricName": "txl0p_power_cycles %", "PerPkg": "1", + "PublicDescription": "Number of QPI qfclk cycles spent in L0p power mode. L0p is a mode where we disable 1/2 of the QPI lanes, decreasing our bandwidth in order to save power. It increases snoop and data transfer latencies and decreases overall bandwidth. This mode can be very useful in NUMA optimized workloads that largely only utilize QPI for snoops and their responses. Use edge detect to count the number of instances when the QPI link entered L0p. Link power states are per link and per direction, so for example the Tx direction could be in one state while Rx was in another.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Cycles in L0", + "Counter": "0,1,2,3", + "EventCode": "0xc", + "EventName": "UNC_Q_TxL0_POWER_CYCLES", + "PerPkg": "1", + "PublicDescription": "Number of QPI qfclk cycles spent in L0 power mode in the Link Layer. L0 is the default mode which provides the highest performance with the most power. Use edge detect to count the number of instances that the link entered L0. Link power states are per link and per direction, so for example the Tx direction could be in one state while Rx was in another. The phy layer sometimes leaves L0 for training, which will not be captured by this event.", "Unit": "QPI LL" }, { - "BriefDescription": "Number of data flits transmitted ", + "BriefDescription": "Tx Flit Buffer Bypassed", + "Counter": "0,1,2,3", + "EventCode": "0x5", + "EventName": "UNC_Q_TxL_BYPASSED", + "PerPkg": "1", + "PublicDescription": "Counts the number of times that an incoming flit was able to bypass the Tx flit buffer and pass directly out the QPI Link. Generally, when data is transmitted across QPI, it will bypass the TxQ and pass directly to the link. However, the TxQ will be used with L0p and when LLR occurs, increasing latency to transfer out to the link.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Cycles Stalled with no LLR Credits; LLR is almost full", + "Counter": "0,1,2,3", + "EventCode": "0x2", + "EventName": "UNC_Q_TxL_CRC_NO_CREDITS.ALMOST_FULL", + "PerPkg": "1", + "PublicDescription": "Number of cycles when the Tx side ran out of Link Layer Retry credits, causing the Tx to stall.", + "UMask": "0x2", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Cycles Stalled with no LLR Credits; LLR is full", + "Counter": "0,1,2,3", + "EventCode": "0x2", + "EventName": "UNC_Q_TxL_CRC_NO_CREDITS.FULL", + "PerPkg": "1", + "PublicDescription": "Number of cycles when the Tx side ran out of Link Layer Retry credits, causing the Tx to stall.", + "UMask": "0x1", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Tx Flit Buffer Cycles not Empty", + "Counter": "0,1,2,3", + "EventCode": "0x6", + "EventName": "UNC_Q_TxL_CYCLES_NE", + "PerPkg": "1", + "PublicDescription": "Counts the number of cycles when the TxQ is not empty. Generally, when data is transmitted across QPI, it will bypass the TxQ and pass directly to the link. However, the TxQ will be used with L0p and when LLR occurs, increasing latency to transfer out to the link.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Transferred - Group 0; Data Tx Flits", "Counter": "0,1,2,3", "EventName": "UNC_Q_TxL_FLITS_G0.DATA", "PerPkg": "1", - "ScaleUnit": "8Bytes", + "PublicDescription": "Counts the number of flits transmitted across the QPI Link. It includes filters for Idle, protocol, and Data Flits. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time (for L0) or 4B instead of 8B for L0p.", "UMask": "0x2", "Unit": "QPI LL" }, { - "BriefDescription": "Number of non data (control) flits transmitted ", + "BriefDescription": "Flits Transferred - Group 0; Idle and Null Flits", + "Counter": "0,1,2,3", + "EventName": "UNC_Q_TxL_FLITS_G0.IDLE", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits transmitted across the QPI Link. It includes filters for Idle, protocol, and Data Flits. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time (for L0) or 4B instead of 8B for L0p.", + "UMask": "0x1", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Transferred - Group 0; Non-Data protocol Tx Flits", "Counter": "0,1,2,3", "EventName": "UNC_Q_TxL_FLITS_G0.NON_DATA", "PerPkg": "1", - "ScaleUnit": "8Bytes", + "PublicDescription": "Counts the number of flits transmitted across the QPI Link. It includes filters for Idle, protocol, and Data Flits. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time (for L0) or 4B instead of 8B for L0p.", + "UMask": "0x4", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Transferred - Group 1; DRS Flits (both Header and Data)", + "Counter": "0,1,2,3", + "EventName": "UNC_Q_TxL_FLITS_G1.DRS", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits trasmitted across the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x18", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Transferred - Group 1; DRS Data Flits", + "Counter": "0,1,2,3", + "EventName": "UNC_Q_TxL_FLITS_G1.DRS_DATA", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits trasmitted across the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x8", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Transferred - Group 1; DRS Header Flits", + "Counter": "0,1,2,3", + "EventName": "UNC_Q_TxL_FLITS_G1.DRS_NONDATA", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits trasmitted across the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x10", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Transferred - Group 1; HOM Flits", + "Counter": "0,1,2,3", + "EventName": "UNC_Q_TxL_FLITS_G1.HOM", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits trasmitted across the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x6", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Transferred - Group 1; HOM Non-Request Flits", + "Counter": "0,1,2,3", + "EventName": "UNC_Q_TxL_FLITS_G1.HOM_NONREQ", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits trasmitted across the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", "UMask": "0x4", "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Transferred - Group 1; HOM Request Flits", + "Counter": "0,1,2,3", + "EventName": "UNC_Q_TxL_FLITS_G1.HOM_REQ", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits trasmitted across the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x2", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Transferred - Group 1; SNP Flits", + "Counter": "0,1,2,3", + "EventName": "UNC_Q_TxL_FLITS_G1.SNP", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits trasmitted across the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x1", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Transferred - Group 2; Non-Coherent Bypass Tx Flits", + "Counter": "0,1,2,3", + "EventCode": "0x1", + "EventName": "UNC_Q_TxL_FLITS_G2.NCB", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits trasmitted across the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for NDR, NCB, and NCS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0xc", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Transferred - Group 2; Non-Coherent data Tx Flits", + "Counter": "0,1,2,3", + "EventCode": "0x1", + "EventName": "UNC_Q_TxL_FLITS_G2.NCB_DATA", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits trasmitted across the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for NDR, NCB, and NCS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x4", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Transferred - Group 2; Non-Coherent non-data Tx Flits", + "Counter": "0,1,2,3", + "EventCode": "0x1", + "EventName": "UNC_Q_TxL_FLITS_G2.NCB_NONDATA", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits trasmitted across the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for NDR, NCB, and NCS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x8", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Transferred - Group 2; Non-Coherent standard Tx Flits", + "Counter": "0,1,2,3", + "EventCode": "0x1", + "EventName": "UNC_Q_TxL_FLITS_G2.NCS", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits trasmitted across the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for NDR, NCB, and NCS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x10", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Transferred - Group 2; Non-Data Response Tx Flits - AD", + "Counter": "0,1,2,3", + "EventCode": "0x1", + "EventName": "UNC_Q_TxL_FLITS_G2.NDR_AD", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits trasmitted across the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for NDR, NCB, and NCS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x1", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Flits Transferred - Group 2; Non-Data Response Tx Flits - AK", + "Counter": "0,1,2,3", + "EventCode": "0x1", + "EventName": "UNC_Q_TxL_FLITS_G2.NDR_AK", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Counts the number of flits trasmitted across the QPI Link. This is one of three 'groups' that allow us to track flits. It includes filters for NDR, NCB, and NCS message classes. Each 'flit' is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four 'fits', each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for example, 8.0 GT/s), the 'transfers' here refer to 'fits'. Therefore, in L0, the system will transfer 1 'flit' at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as 'data' bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual 'data' and an additional 16 bits of other information. To calculate 'data' bandwidth, one should therefore do: data flits * 8B / time.", + "UMask": "0x2", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Tx Flit Buffer Allocations", + "Counter": "0,1,2,3", + "EventCode": "0x4", + "EventName": "UNC_Q_TxL_INSERTS", + "PerPkg": "1", + "PublicDescription": "Number of allocations into the QPI Tx Flit Buffer. Generally, when data is transmitted across QPI, it will bypass the TxQ and pass directly to the link. However, the TxQ will be used with L0p and when LLR occurs, increasing latency to transfer out to the link. This event can be used in conjunction with the Flit Buffer Occupancy event in order to calculate the average flit buffer lifetime.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "Tx Flit Buffer Occupancy", + "Counter": "0,1,2,3", + "EventCode": "0x7", + "EventName": "UNC_Q_TxL_OCCUPANCY", + "PerPkg": "1", + "PublicDescription": "Accumulates the number of flits in the TxQ. Generally, when data is transmitted across QPI, it will bypass the TxQ and pass directly to the link. However, the TxQ will be used with L0p and when LLR occurs, increasing latency to transfer out to the link. This can be used with the cycles not empty event to track average occupancy, or the allocations event to track average lifetime in the TxQ.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "VNA Credits Returned", + "Counter": "0,1,2,3", + "EventCode": "0x1c", + "EventName": "UNC_Q_VNA_CREDIT_RETURNS", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Number of VNA credits returned.", + "Unit": "QPI LL" + }, + { + "BriefDescription": "VNA Credits Pending Return - Occupancy", + "Counter": "0,1,2,3", + "EventCode": "0x1b", + "EventName": "UNC_Q_VNA_CREDIT_RETURN_OCCUPANCY", + "ExtSel": "1", + "PerPkg": "1", + "PublicDescription": "Number of VNA credits in the Rx side that are waitng to be returned back across the link.", + "Unit": "QPI LL" } ] |