On Mon, Nov 07, 2022 at 03:48:43PM -0800, Dan Williams wrote: > Alison Schofield wrote: > > On Sun, Nov 06, 2022 at 03:48:01PM -0800, Dan Williams wrote: > > > Allow for: > > > > > > cxl create-region -d decoderX.Y > > > > > > ...to assume (-m -w $(count of memdevs beneath decoderX.Y)) > > > > I'm not understanding what the change is here. Poked around a bit > > and still didn't get it. Help! > > > > Leaving out the -m leads to this: > > $ cxl create-region -d decoder3.3 mem0 mem1 > > cxl region: parse_create_options: must specify option for target object > > types (-m) > > cxl region: cmd_create_region: created 0 regions > > > > Leaving out the the -m and the memdevs fails because the memdev order is > > not correct. > > $ cxl create-region -d decoder3.3 > > cxl region: create_region: region5: failed to set target0 to mem1 > > cxl region: cmd_create_region: created 0 regions > > > > This still works, where I give the -m and the correct order of memdevs. > > cxl create-region -m -d decoder3.3 mem0 mem1 > > Oh, I was not expecting the lack of automatic memdev sorting to rear its > head so quickly, and thought that "cxl list" order was good enough for > most configurations.
I wasn't clear on what was being advertised as supported with this change. I didn't read this as an announcement of automatic region creation, but it seemed you were hinting at it. > > Can provide more details on your configuration in this case? If this is > current cxl_test then I already do not expect it to work with anything > but decoder3.4 since the other decoders have more complicated ordering > constraints. > > I.e. your: > > cxl create-region -d decoder3.3 > > ...worked as expected in that it found some memdevs to attempt to create > the region, but you got unlucky in the sense that the default order that > 'cxl list' returns memdevs was incompatible with creating a region. Pretty much exactly as you say above. My example was w cxl_test decoder3.3, w 2 HB's. The automagic worked fine w decoder3.4 w 1 HB.
