Jonathan Cameron wrote:
> On Mon, 06 Feb 2023 13:52:05 -0700
> Dave Jiang <dave.jiang@xxxxxxxxx> wrote:
>
> > Export qtg_id sysfs attributes for the respective ram and pmem DPA range of
> > a CXL device. The QTG ID should show up as
> > /sys/bus/cxl/devices/memX/pmem/qtg_id for pmem or as
> > /sys/bus/cxl/devices/memX/ram/qtg_id for ram.
>
> This doesn't extend to devices with say multiple DSMAS regions
> for RAM with different access characteristics. Think of a device
> with HBM and DDR for example, or a mix of DDR4 and DDR5.
>
> Once we are dealing with memory pools of significant size there
> are very likely to be DPA regions with different characteristics.
>
> So minimum I'd suggest is leave space for an ABI that might look like.
>
> mem/range0_qtg_id
> mem/range1_qtg_id
> mem/range0_base
> mem/range0_length
> mem/range1_base
> mem/range1_length
> etc but with the flexibility to not present the rangeX_base/length stuff if there
> is only one presented. For now just present the range0_qtg_id
I do agree that there should be some mechanism to dump this information,
I am just not yet sure the should prioritize for the case where someone
builds multiple performance classes per partition type. There would seem
to be design pressure against that given you can not allocate regions
out of DPA order otherwise capacity gets stranded.
So I am thinking something like a debugfs interface to dump all the
ranges but otherwise leave memX/{ram,pmem,dcd[0-7]} with a single
qtg-id each.
If it turns out later that devices really call for multiple qtg-ids
per-partition as a first-class ABI then there's the option of something
like:
memX/ram/qtg_id
memX/ram/qtg_id1
memX/ram/qtg_id2
memX/ram/qtg_range/
memX/ram/qtg1_range/
memX/ram/qtg2_range/
...but I hope the primary use case for devices with multiple performance
ranges is due to having 'pmem' or 'dcd' in addition to 'ram'.
