Skip to content

Commit

Permalink
adding supporting text for cc_ncunits
Browse files Browse the repository at this point in the history
  • Loading branch information
@ved-rivos
ved-rivos committed Oct 2, 2023
1 parent 155b189 commit ad9437d
Showing 1 changed file with 72 additions and 37 deletions.
109 changes: 72 additions & 37 deletions qos_capacity.adoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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%]
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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 <<CC_ALLOC_OP>>. 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 <<CC_ALLOC_OP>>. 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`)
Expand All @@ -305,35 +326,40 @@ 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.
|===

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
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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`)
Expand All @@ -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]
====
Expand All @@ -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`)
Expand Down

0 comments on commit ad9437d

Please sign in to comment.