Re: [Qemu-devel] [RFC 0/3] qmp: Return extra information on qom-list-types

[Eduardo Habkost]

On Wed, May 24, 2017 at 02:13:16PM +0200, Markus Armbruster wrote:
> Eduardo Habkost <address@hidden> writes:
> 
> > On Tue, May 23, 2017 at 04:12:43PM +0200, Markus Armbruster wrote:
> >> Eduardo Habkost <address@hidden> writes:
> >> 
> >> > This series adds 'abstract' and 'parent-types' fields to the
> >> > output of qom-list-types.
> >> 
> >> Peeking at PATCH 3, it looks like 'parent-types' is the transitive
> >> closure of the single direct parent type (TypeImpl member parent_type).
> >> Do we need information on interfaces as well?
> >
> > I think we should, but it is more complex so I plan to do in a
> > separate patch.
> 
> Okay.
> 
> >> > For reference, below are the sizes of the output of
> >> > "qom-list-types abstract=true" on qemu-system-x86_64, before and
> >> > after applying the patches:
> >> >
> >> > * before: 11724 bytes
> >> > * with 'abstract' field: 20119 bytes
> >> > * with 'abstract' and 'parent-types': 44383 bytes
> >> 
> >> Obvious ways to save space:
> >> 
> >> * Make 'abstract' optional, default to false, present only when
> >>   necessary (79 out of 456 times right now)
> >
> > Good idea.
> >
> >> 
> >> * Pare down 'parent-types' to *direct* parent types.  The indirect ones
> >>   are redundant.
> >
> > On the one hand, I assume clients don't care if a given type is a
> > direct parent or indirect parent, and including only the direct
> > parent type will require them to make extra queries.
> 
> Given the direct parents, computing their transitive closure is trivial.
> So a single query should suffice.

If you have the full list, yes.  I was thinking of something like
asking "does type FOO is a (direct or indirect) child of BAR?".

"qom-list-types implements=FOO" wouldn't suffice.

"qom-list-types implements=BAR" would be enough, but it would
also return all subtypes of BAR.

However, I think this example is not very realistic.  libvirt,
for example, does query everything about QEMU capabilities only
once, and then cache it.  Even if a client doesn't cache it, the
size of "qom-list-types implements=BAR" should be reasonable.

> 
> > On the other hand, if the client wants to save a few queries it
> > can use the "implements" argument, already? Not sure.
> >
> >> 
> >> A less obvious way:
> >> 
> >> * 'parent-types' defines a relation with adjacency lists.  If the
> >>   relation is tree-shaped, we can send the tree instead, i.e. a tree of
> >>   device names rather than list of (device name, adjacency list).  New
> >>   command unless we're willing to break qom-list-types.
> >> 
> >> > I'm not sure if extending qom-list-types with this info is the
> >> > right way to go, or if we should keep qom-list-types as-is and
> >> > add a new "query-qom-type" QMP command to query info on one QOM
> >> > type at a time.
> >> 
> >> Might lead to more traffic rather than less.  Depends on what
> >> information the client needs to query.
> >
> > I think queries that return all available QOM types are likely to
> > (should?) be cached by clients.
> 
> Perhaps libvirt developers can help us here.

The only usage of qom-list-types I found in libvirt has no
command arguments, and is called by code that checks for cached
information first.

> 
> >                                  I believe the size will stay
> > acceptable if we implement the two suggestions above.
> 
> Please do.

-- 
Eduardo