Re: [PATCH RFC v3 3/3] mhsld: implement MHSLD device

[Gregory Price]

On Fri, Dec 13, 2024 at 04:18:36PM +0000, Jonathan Cameron wrote:
> On Thu, 12 Dec 2024 14:52:02 -0500
> Gregory Price <gourry@gourry.net> wrote:
> 
> I don't think anyone is going to do 2MiB granularity on a real device
> (or at least not for bulk capacity) so the necessary data may not be that 
> large.
> Obviously the cost of updating it will be higher, but meh, that's not that
> common an operation.
> 
> > 
> > >  and we can have
> > > richer info.  Having to chat to each qmp interface independently works 
> > > fine is
> > > also a bit more complex than I think we would eventually want.
> > >   
> > 
> > This is a small component in someone's fabric manager that translates their
> > requests into QMP commands.  Whatever we ultimately decide on, the 
> > complexity
> > here is about the same.
> 
> It's the qmp commands to a bunch of different qemu instances pretending to be 
> one
> Multi Head device.
> Sure we can insert a proxy to act as that one, but then we more or less
> have an external process mediating that.
> 

I'm not against changing this, I just think it's going to increase complexity
for little value.  

I personally like the idea of keeping it the way it is and slapping a small
proxy on top that emulates the "out of band" interface to the device - but
all it does behind the scenes is send out a QMP command (that already exists)
to a guest that registered itself with the proxy.

This separates the complexity of implementing FMAPI functionality and the
complexity of how an individual instance of QEMU go about handling
add/access/remove semantics for DCD events.

The annoying thought experiment here is when someone wants their in-band
host interface to have access to the FMAPI

great now i've made myself grumpy
 
> > 
> > > Having a solution in place though will make it much easier to move towards
> > > an eventual upstreamable solution. This is a great place to start from!
> > > 
> > > Jonathan
> > >   
> > > > +/*
> > > > + * We limit the number of heads to prevent the shared state
> > > > + * region from becoming a major memory hog.  We need 512MB of
> > > > + * memory space to track 8-host ownership of 4GB of memory in
> > > > + * blocks of 2MB.  This can change if the block size is increased.  
> > > 
> > > I'm lost what makes up that size?
> > >   
> > 
> > I think the math is wrong here, we may have calculated based on
> > a larger capacity.  I need to go back and look at how we came to 512MB.
> 4TB maybe?
> 
> Jonathan

Yeah that's probably what it was.  I think that's what I was basing it off of
at the time.

~Gregory