Message ID | 1390488396-16538-6-git-send-email-akong@redhat.com |
---|---|
State | New |
Headers | show |
Il 23/01/2014 15:46, Amos Kong ha scritto: > +The whole schema information will be returned in one go, it contains > +all the schema entries. It doesn't support to be filtered by type > +or name. Currently it takes about 4 seconds to return about 1.7M string. > +Management only needs to execute this command once after installing > +QEMU package. > + This is quite a lot. Without comments, qapi-schema.json is 27k. I'd expect the DataObject representation to be in the ballpark of 100-200k. I don't understand why is it necessary to expand all the types in the result? Paolo
On 01/24/2014 04:43 AM, Paolo Bonzini wrote: > Il 23/01/2014 15:46, Amos Kong ha scritto: >> +The whole schema information will be returned in one go, it contains >> +all the schema entries. It doesn't support to be filtered by type >> +or name. Currently it takes about 4 seconds to return about 1.7M string. >> +Management only needs to execute this command once after installing >> +QEMU package. >> + But management has to call the command for every variant of the qemu binary that it plans on driving - on a system with multiple qemu-* for targetting multiple target types, this starts to border on unacceptably long for libvirt. And while libvirt might use this command to learn about what is supported for a handful of specific commands, making libvirt store 1.7M + additional memory for its JSON parse of that data per qemu starts to add up fast, if libvirt were to keep that data around for the life of libvirtd rather than just learning what it needs from the string and discarding the string up front. We've just made an argument for WHY we need filtering to just a given type/command. > > This is quite a lot. > > Without comments, qapi-schema.json is 27k. I'd expect the DataObject > representation to be in the ballpark of 100-200k. > > I don't understand why is it necessary to expand all the types in the > result? Any time a type is returned at the top level in the same query (such as in your global query), management can look up any unexpanded type in the same result. I could understand expanding the results when returning only a subset of the tree (that is, when filtering is added, asking for a single type should give me all information about that type, including the subtypes it references, without me having to make multiple calls to learn about the subtypes), but even then, it might be worth having an optional boolean flag on the query that says whether I want expansion vs. compact results.
diff --git a/docs/qmp-full-introspection.txt b/docs/qmp-full-introspection.txt index 8ecbc0c..4cb1b9e 100644 --- a/docs/qmp-full-introspection.txt +++ b/docs/qmp-full-introspection.txt @@ -8,6 +8,44 @@ information, it returns a range of schema structs, which contain the useful metadata to help management to check supported features, QMP commands detail, etc. +== Usage == + +Json schema: + { 'type': 'NameInfo', 'data': {'*name': 'str'} } + { 'command': 'query-name', 'returns': 'NameInfo' } + +Execute QMP command: + + { "execute": "query-qmp-schema" } + +Returns: + + { "return": [ + { + "name": "query-name", + "type": "command", + "returns": { + "name": "NameInfo", + "type": "type", + "data": [ + { + "name": "name", + "optional": true, + "recursive": false, + "type": "str" + } + ] + } + }, + ... + } + +The whole schema information will be returned in one go, it contains +all the schema entries. It doesn't support to be filtered by type +or name. Currently it takes about 4 seconds to return about 1.7M string. +Management only needs to execute this command once after installing +QEMU package. + == 'DataObject' union == { 'union': 'DataObject',
Signed-off-by: Amos Kong <akong@redhat.com> --- docs/qmp-full-introspection.txt | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+)