On Fri, Apr 26, 2024 at 04:55:55PM +0100, Jonathan Cameron wrote: > On Wed, 24 Apr 2024 10:33:33 -0700 > Ira Weiny <ira.we...@intel.com> wrote: > > > Markus Armbruster wrote: > > > nifan....@gmail.com writes: > > > > > > > From: Fan Ni <fan...@samsung.com> > > > > > > > > Since fabric manager emulation is not supported yet, the change > > > > implements > > > > the functions to add/release dynamic capacity extents as QMP > > > > interfaces. > > > > > > Will fabric manager emulation obsolete these commands? > > > > I don't think so. In the development of the kernel, I see these being > > valuable to do CI and regression testing without the complexity of an FM. > > Fully agree - I also long term see these as the drivers for one > possible virtualization stack for DCD devices (whether it turns > out to be the way forwards for that is going to take a while to > resolve!) > > It doesn't make much sense to add a fabric manager into that flow > or to expose an appropriate (maybe MCTP) interface from QEMU just > to poke the emulated device. > > Jonathan >
fwiw it's useful in modeling the Orchestrator/Fabric Manager interaction, since you can basically build a little emulated MHD FM-LD on top of this. You basically just put a tiny software layer in front that converts what would be MCTP or whatever commands into QMP commands forwarded to the appropriate socket. When a real device comes around, you just point it at the real thing instead of that small software layer. But for the actual fabric manager, less useful. (Also, if you're confused, it's because fabric manager is such an overloaded term *laughcry*) ~Gregory
