Re: [PATCH v9 00/19] DCD: Add support for Dynamic Capacity Devices (DCD)

[Gregory Price]

On Sun, Apr 13, 2025 at 05:52:08PM -0500, Ira Weiny wrote:
> A git tree of this series can be found here:
> 
> 	https://github.com/weiny2/linux-kernel/tree/dcd-v6-2025-04-13
> 
> This is now based on 6.15-rc2.
> 

Extreme necro-bump for this set, but i wonder what folks opinion is on
DCD support if we expose a new region control pattern ala:

https://lore.kernel.org/linux-cxl/20260129210442.3951412-1-gourry@xxxxxxxxxx/

The major difference would be elimination of sparse-DAX, which i know
has been a concern, in favor of a per-region-driver policy on how to
manage hot-add/remove events.

Things I've discussed with folks in different private contexts

sysram usecase:
----
  echo regionN > decoder0.0/create_dc_region
  /* configure decoders */
  echo regionN > cxl/drivers/sysram/bind

tagged extents arrive and leave as a group, no sparseness
    extents cannot share a tag unless they arrive together
    e.g. set(A) & set(B) must have different tags
    add and expose daxN.M/uuid as the tag for collective management

Can decide whether linux wants to support untagged extents
    cxl_sysram could choose to track and hotplug untagged extents
    directly without going through DAX. Partial release would be
    possible on a per-extent granularity in this case.
----


virtio usecase:  (making some stuff up here)
----
  echo regionN > decoder0.0/create_dc_region
  /* configure decoders */
  echo regionN > cxl/drivers/virtio/bind

tags are required and may imply specific VM routing
    may or may not use DAX under the hood

extents may be tracked individually and add/removed individually
    if using DAX, this implies 1 device per extent.
    This probably requires a minimum extent size to be reasonable.

Does not expose the memory as SysRAM, instead builds new interface
    to handle memory management message routing to/from the VMM
    (N_MEMORY_PRIVATE?)
----


devdax usecase (FAMFS?)
---- 
  echo regionN > decoder0.0/create_dc_region
  /* configure decoders */
  echo regionN > cxl/drivers/devdax/bind

All sets of extents appear as new DAX devices
Tags are exposed via daxN.M/uuid
Tags are required
   otherwise you can't make sense of what that devdax represents
---

Begs the question:
   Do we require tags as a baseline feature for all modes?
   No tag - no service.
   Heavily implied:  Tags are globally unique (uuid)

But I think this resolves a lot of the disparate disagreements on "what
to do with tags" and how to manage sparseness - just split the policy
into each individual use-case's respective driver.

If a sufficiently unique use-case comes along that doesn't fit the
existing categories - a new region-driver may be warranted.

~Gregory