From ad9437d7e35a458f181df50493b4d423308ce25a Mon Sep 17 00:00:00 2001 From: Ved Shanbhogue Date: Mon, 2 Oct 2023 09:46:51 -0500 Subject: [PATCH] adding supporting text for cc_ncunits --- qos_capacity.adoc | 109 ++++++++++++++++++++++++++++++---------------- 1 file changed, 72 insertions(+), 37 deletions(-) diff --git a/qos_capacity.adoc b/qos_capacity.adoc index ff61379..4a0b88a 100644 --- a/qos_capacity.adoc +++ b/qos_capacity.adoc @@ -5,6 +5,24 @@ Controllers, such as cache controllers, that support capacity allocation and usage monitoring provide a memory-mapped capacity-controller QoS register interface. +The capacity controller allocates memory capacity in multiples of capacity +units. A group of these units is referred to as a _capacity block_. Capacity +blocks can be allocated to one or more workloads. When a workload requests +capacity allocation, the capacity is allocated using capacity units situated +within the capacity blocks assigned to the workload. Capacity blocks can also be +shared among one or more workloads. Optionally, the capacity controller may +allow configuration of a limit on the maximum number of capacity units that can +be occupied in the capacity blocks allocated to a given workload. + +[NOTE] +==== +For example, a cache controller may allocate capacity in multiples of cache +blocks. In this context, a cache block serves as a capacity unit, and a group of +cache blocks forms a _capacity block_. A cache controller supporting capacity +allocation by ways might define a _capacity block_ to be the cache blocks in one +way of the cache. +==== + [[CC_REG]] .Capacity-controller QoS register layout [width=100%] @@ -75,8 +93,9 @@ of an allocatable capacity block. [NOTE] ==== -For example, a cache controller that supports capacity allocation by ways may -report the number of ways as the number of allocatable capacity blocks. +For example, a cache controller that defines a way of the cache as a _capacity +block_ may report the number of ways as the number of allocatable capacity +blocks. ==== If `FRCID` is 1, the controller supports an operation to flush and deallocate @@ -289,13 +308,15 @@ access-type then the `AT` field is read-only zero. The `OP`, `AT`, and `RCID` are WARL fields. -The `OP` field used to instruct the capacity controller to perform an -operation listed in <>. Some operations require specifying the capacity -blocks to operate on. The capacity blocks, in the form of a bitmask, for such -operations are specified in the `cc_block_mask` register. To request operations that -need a capacity block mask to be specified, software must first program the -`cc_block_mask` register and then request the operation using the `cc_alloc_ctl` -register. +The `OP` field is used to instruct the capacity controller to perform an +operation listed in <>. Some operations necessitate the +specification of the capacity blocks to act upon. For such operations, the +targeted capacity blocks are designated in the form of a bitmask in the +`cc_block_mask` register. Additionally, certain operations require the capacity +unit limit to be defined in the `cc_cunits` register. To execute operations that +require a capacity block mask and/or a capacity unit limit, software must first +program the `cc_block_mask` and/or the `cc_cunits` register, followed by +initiating the operation via the `cc_alloc_ctl` register. [[CC_ALLOC_OP]] .Capacity allocation operations (`OP`) @@ -305,23 +326,27 @@ register. |Operation | Encoding ^| Description |-- | 0 | Reserved for future standard use. |`CONFIG_LIMIT`| 1 | Configure a capacity allocation for requests by - `RCID` and of access-type `AT`. The capacity + `RCID` and of access-type `AT`. The capacity blocks allocation is specified in the `cc_block_mask` - register. + register, and a limit on capacity units is + specified in the `cc_cunits` register. |`READ_LIMIT` | 2 | Read back the previously configured capacity allocation for requests by `RCID` and of - access-type `AT`. The configured allocation is - returned as a bit-mask in the `cc_block_mask` + access-type `AT`. The configured capacity block + allocation is returned as a bit-mask in the + `cc_block_mask` register, and the configured limit + on capacity units is available in the `cc_cunits` register on successful completion of the operation. |`FLUSH_RCID` | 3 | Deallocate the capacity used by the specified `RCID` and access-type `AT`. This operation is - supported if the `capabilities.FRCID` bit is 1.+ - + - The `cc_block_mask` register is not used for this - operation.+ - + - The configured capacity allocation is not changed by - this operation. + supported if the `capabilities.FRCID` bit is 1. + + + + The `cc_block_mask` and `cc_cunits` registers + are not used for this operation. + + + + The configured capacity block allocation or the + capacity unit limit is not changed by this + operation. | -- | 4-23 | Reserved for future standard use. | -- | 24-31 | Designated for custom use. |=== @@ -329,11 +354,12 @@ register. Capacity controllers enumerate the allocatable capacity blocks in the `NCBLKS` field of the `cc_capabilities` register. The `cc_block_mask` register is programmed with a bit-mask where each bit represents a capacity block for the -operation. +operation. A limit on the capacity unit, if supported, that can be occupied in +the allocated capacity blocks may be programmed in the `cc_cunits` register. A capacity allocation must be configured for each supported access-type by the controller. An implementation that does not support capacity allocation per -access-type may hardwire the `AT` field to 0 and associate use the same capacity +access-type may hardwire the `AT` field to 0 and associate the same capacity allocation configuration for requests with all access-types. When capacity allocation per access-type is supported, identical limits may be configured for two or more access-types if different capacity allocation per access-type is not @@ -366,6 +392,14 @@ allow differentiated treatment in another capacity and/or bandwidth controller. | `RCID=6`, `AT=0` | `0` | `0` | `0` | `1` | `1` | `0` | `0` | `0` | `RCID=6`, `AT=1` | `0` | `0` | `0` | `1` | `1` | `0` | `0` | `0` |=== + +Some controllers allow setting a limit on capacity units in allocated capacity +blocks. In exclusive allocations, like for `RCID=5`, the limit can be the +capacity block's maximum capacity. For shared allocations, such as between +`RCID=3` and `RCID=6`, individual limits can be set. For example, if two +capacity blocks represent 100 units and `RCID=3` has a 30-unit limit while +`RCID=6` has a 70-unit limit, they can use 30% and 70% of the shared capacity +blocks, respectively. ==== The `FLUSH_RCID` operation may incur a long latency to complete. New requests to @@ -418,11 +452,10 @@ write to the `cc_alloc_ctl` register. |=== When the `BUSY` bit is set to 1, the behavior of writes to the `cc_alloc_ctl` -register or to the `cc_block_mask` register is `UNSPECIFIED`. Some -implementations may ignore the second write and others may perform the -operation determined by the second write. To ensure proper operation, software -must verify that `BUSY` bit is 0 before writing the `cc_alloc_ctl` register or -the `cc_block_mask` register. +register, `cc_cunits` register, or to the `cc_block_mask` register is +`UNSPECIFIED`. Some implementations may ignore the second write and others may +perform the operation determined by the second write. To ensure proper operation, +software must verify that `BUSY` bit is 0 before writing any of these registers. [[CC_BMASK]] === Capacity block mask (`cc_block_mask`) @@ -447,14 +480,16 @@ have a value of 0. The process of configuring capacity allocation for an `RCID` and `AT` begins by programming the `cc_block_mask` register with a bit-mask that identifies the -capacity blocks to be allocated. Next, the `cc_alloc_ctl register` is written to -request a `CONFIG_LIMIT` operation for the `RCID` and `AT`. Once a capacity -allocation limit has been established, a request may be allocated capacity in the -capacity blocks allocated to the `RCID` and `AT` associated with the request. It -is important to note that at least one capacity block must be allocated using -`cc_block_mask` when allocating capacity, or else the operation will fail with -`STATUS=5`. Overlapping capacity block masks among `RCID` and/or `AT` are -allowed to be configured. +capacity blocks to be allocated and, if supported, the `cc_cunits` register with +a limit on the capacity units that may be occupied in those capacity blocks. +Next, the `cc_alloc_ctl register` is written to request a `CONFIG_LIMIT` +operation for the `RCID` and `AT`. Once a capacity allocation limit has been +established, a request may be allocated capacity in the capacity blocks +allocated to the `RCID` and `AT` associated with the request. It is important to +note that at least one capacity block must be allocated using `cc_block_mask` +when allocating capacity, or else the operation will fail with `STATUS=5`. +Overlapping capacity block masks among `RCID` and/or `AT` are allowed to be +configured. [NOTE] ==== @@ -465,10 +500,10 @@ selected and mask of the selected ways must be programmed in `cc_block_mask` whe requesting the `CONFIG_LIMIT` operation. ==== -To read the capacity allocation limit for an `RCID` and `AT`, the controller +To read the capacity block allocation for an `RCID` and `AT`, the controller provides the `READ_LIMIT` operation which can be requested by writing to the `cc_alloc_ctl` register. Upon successful completion of the operation, the -`cc_block_mask` register holds the configured capacity allocation limit. +`cc_block_mask` register holds the configured capacity block allocation. [[CC_CUNITS]] === Capacity units (`cc_cunits`)