KEP-4815 DRA Partitionable devices design update

Author: mortent

keps/sig-node/4815-dra-partitionable-devices/README.md

@@ -267,12 +267,16 @@ The basic idea is the following:
    footprint of each device when a common set of attributes and capacities can
    be applied. The mixins themselves are introduced as a list of top-level
    objects directly next to the list of `Devices` inside a `ResourceSlice`.
-   They are not allocatable on their own.
+   They are not allocatable on their own. Entries in the `Includes` list can
+   reference mixins in any `ResourceSlice` in the same pool. References to
+   mixins in other pools are not allowed.
 
 1. The `ConsumesCapacityFrom` field contains a list of *other* devices where the
    capacity of the current device should be consumed if the scheduler decides
    to allocate it. This essentially removes that capacity from any referenced
-   devices, rendering them unallocatable on their own.
+   devices, rendering them unallocatable on their own. Entries in the 
+   `ConsumesCapacityFrom` list can reference devices in any `ResourceSlice` in
+   the same pool. References to devices in other pools are not allowed.
 
 With these additions in place, the scheduler has everything it needs to support
 the dynamic allocation of both full devices and their (possibly overlapping)
@@ -385,11 +389,16 @@ type CompositeDevice struct {
 	//
 	// The propertes of each included mixin are applied to this device in
 	// order. Conflicting properties from multiple mixins are taken from the
-	// last mixin listed that contains them.
+	// last mixin listed that contains them. Properties set on the device will
+	// always override properties from mixins.
+	//
+	// The mixins referenced here must be defined in the same pool as the
+	// current device, but can be defined in any ResourceSlice within the pool.
 	//
 	// The maximum number of mixins that can be included is 8.
 	//
 	// +optional
+	// +listType=atomic
 	Includes []DeviceMixinRef `json:"includes,omitempty"`
 
 	// ConsumesCapacityFrom defines the set of devices where any capacity
@@ -399,10 +408,14 @@ type CompositeDevice struct {
 	//
 	// Conflicting capacities from multiple devices are taken from the
 	// last device listed that contains them.
+    //
+	// The devices referenced here must be defined in the same pool as the
+	// current device, but can be defined in any ResourceSlice within the pool.
 	//
-	// The maximum number of devices that can be referenced is 8.
+	// Only a single entry is allowed. This might be extended in the future.
 	//
 	// +optional
+	// +listType=atomic
 	ConsumesCapacityFrom []DeviceRef `json:"consumesCapacityFrom,omitempty"`
 
 	// Attributes defines the set of attributes for this device.
@@ -618,20 +631,15 @@ follows:
     "sink" of capacity, pulling from "source" devices in order to satisfy its
     own capacity when allocated.
 
-The scheduler must track the available capacity from all "source" devices, and
+The scheduler must track the availablity of the "source" device, and
 pull from it whenever it decides to allocate a "sink" device.
 
 So long as no other devices have been allocated that reference a given "source"
 device in their `ConsumesCapacityField`, it is free to be allocated by the
 scheduler. However, as soon as its capacity has been pulled down by any given
 "sink" device, it can no longer be allocated until its capacity is freed again.
 
-Likewise, so long as all of the advertised capacity of a "sink" device can be
-satisfied by the set of "source" devices it references in its
-`ConsumesCapacityFrom` field, it is free to be allocated by the scheduler.
-However, if any of its advertised capacity cannot be satisfied by one of its
-referenced "source" devices, then it cannot be allocated until that capacity is
-freed by some other device.
+Likewise, a "sink" device can be allocated if it's "source" device is available.
 
 Note that in order to support nested partitioning, a "sink" device *may*
 provide a reference to another "sink" device in its `ConsumesCapacityFrom`
@@ -647,7 +655,12 @@ When such a device is allocated, the scheduler will need to track the full
 capacity required to satisfy each of the sink devices along the chain. In this
 way, all intermediate sink devices will essentially be rendered
 "unschedulable", with the last-level sink device pulling its capacity from the
-devices it references directly.
+device it references directly.
+
+The API defines the `ConsumesCapacityFrom` field as a list of `DeviceRef` entries.
+While we only allow a single entry in this list, effectily forcing the partitioning
+of a device to form a tree of devices that consumes capacity, this can be extended
+in the future to allow a device to reference multiple "source" devices. 
 
 ### Putting it all together for the MIG use-case
 

keps/sig-node/4815-dra-partitionable-devices/kep.yaml

@@ -2,6 +2,7 @@ title: DRA Partitionable Devices
 kep-number: 4815
 authors:
   - "@klueska"
+  - "@mortent"
 owning-sig: sig-node
 participating-sigs:
   - sig-scheduling