From: Alexey Kirillov <lekiravi@yandex-team.ru>
To: Markus Armbruster <armbru@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
Thomas Huth <thuth@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Stefan Weil <sw@weilnetz.de>, Jason Wang <jasowang@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Vincenzo Maffione <v.maffione@gmail.com>,
"yc-core@yandex-team.ru" <yc-core@yandex-team.ru>,
Paolo Bonzini <pbonzini@redhat.com>,
Samuel Thibault <samuel.thibault@ens-lyon.org>,
Giuseppe Lettieri <g.lettieri@iet.unipi.it>,
Luigi Rizzo <rizzo@iet.unipi.it>
Subject: Re: [PATCH v3 1/4] qapi: net: Add query-netdevs command
Date: Tue, 08 Sep 2020 18:52:39 +0300 [thread overview]
Message-ID: <18211599579782@mail.yandex-team.ru> (raw)
In-Reply-To: 871rjdrca0.fsf@dusky.pond.sub.org
07.09.2020, 15:40, "Markus Armbruster" <armbru@redhat.com>:
> Alexey Kirillov <lekiravi@yandex-team.ru> writes:
>
>> Hi!
>>
>> 02.09.2020, 14:23, "Markus Armbruster" <armbru@redhat.com>:
>>> Alexey Kirillov <lekiravi@yandex-team.ru> writes:
>>>
>>>> Add a qmp command that provides information about currently attached
>>>> backend network devices and their configuration.
>>>>
>>>> Signed-off-by: Alexey Kirillov <lekiravi@yandex-team.ru>
>>>
>>> [...]
>>>> diff --git a/qapi/net.json b/qapi/net.json
>>>> index ddb113e5e5..c09322bb42 100644
>>>> --- a/qapi/net.json
>>>> +++ b/qapi/net.json
>>>> @@ -714,3 +714,71 @@
>>>> ##
>>>> { 'event': 'FAILOVER_NEGOTIATED',
>>>> 'data': {'device-id': 'str'} }
>>>> +
>>>> +##
>>>> +# @NetdevInfo:
>>>> +#
>>>> +# Configuration of a network backend device (netdev).
>>>> +#
>>>> +# @id: Device identifier.
>>>> +#
>>>> +# @type: Specify the driver used for interpreting remaining arguments.
>>>> +#
>>>> +# @peer-id: Connected frontend network device identifier.
>>>> +#
>>>> +# Since: 5.2
>>>> +##
>>>> +{ 'union': 'NetdevInfo',
>>>> + 'base': { 'id': 'str',
>>>> + 'type': 'NetClientDriver',
>>>> + '*peer-id': 'str' },
>>>> + 'discriminator': 'type',
>>>> + 'data': {
>>>> + 'user': 'NetdevUserOptions',
>>>> + 'tap': 'NetdevTapOptions',
>>>> + 'l2tpv3': 'NetdevL2TPv3Options',
>>>> + 'socket': 'NetdevSocketOptions',
>>>> + 'vde': 'NetdevVdeOptions',
>>>> + 'bridge': 'NetdevBridgeOptions',
>>>> + 'netmap': 'NetdevNetmapOptions',
>>>> + 'vhost-user': 'NetdevVhostUserOptions',
>>>> + 'vhost-vdpa': 'NetdevVhostVDPAOptions' } }
>>>
>>> This is union Netdev plus a common member @peer-id, less the variant
>>> members for NetClientDriver values 'nic' and 'hubport'.
>>>
>>> Can 'type: 'nic' and 'type': 'hubport' occur?
>>
>> No, it can't. We don't support NIC/hubport in query-netdevs, so we neither create this
>> structure for them, nor store config.
>
> Same for 'none', I guess.
>
> As defined, NetdevInfo allows types 'none', 'nic', and 'hubport', it
> just has no variant members for them. The fact that they can't occur is
> not coded into the type, and therefore not visible in introspection.
>
> To make introspection more precise, we'd have to define a new enum type.
> How much that would complicate the C code is unclear.
>
> Do we need it to be more precise? Eric, got an opinion?
>
> Existing type Netdev has the same issue for 'none' and 'nic'. I guess
> this is so we can reuse the type for -net. Not sure that's a good idea,
> but not this patch's problem.
>
>>> What's the use case for @peer-id?
>>
>> Main reason is to provide information "is this backend connected to frontend device".
>> User also may want to know which backend used for frontend device.
>>
>>> Assuming we want @peer-id: its documentation is too vague. Cases:
>>>
>>> * Not connected to a frontend: I guess @peer-id is absent then.
>>
>> Absolutely correct.
>>
>>> * Connected to a frontend
>>>
>>> - that has a qdev ID (the thing you set with -device id=...): I guess
>>> it's the qdev ID then.
>>
>> Correct.
>>
>>> - that doesn't have a qdev ID: anyone's guess.
>>
>> We use field "name" of structure NetClientState, so if there is no direct ID setting,
>> there must be generated name (in format "model.id").
>
> Perhaps:
>
> # @peer-id: the connected network backend's name (absent if no
> # backend is connected)
Maybe you mean:
# @peer-id: The connected frontend network device name (absent if no frontend
# is connected).
In any case, thanks for pointing. I'll add this in the next patch version.
>>>> +
>>>> +##
>>>> +# @query-netdevs:
>>>> +#
>>>> +# Get a list of @NetdevInfo for all virtual network backend devices (netdevs).
>>>> +#
>>>> +# Returns: a list of @NetdevInfo describing each netdev.
>>>> +#
>>>> +# Since: 5.2
>>>> +#
>>>> +# Example:
>>>> +#
>>>> +# -> { "execute": "query-netdevs" }
>>>> +# <- { "return": [
>>>> +# {
>>>> +# "ipv6": true,
>>>> +# "ipv4": true,
>>>> +# "host": "10.0.2.2",
>>>> +# "ipv6-dns": "fec0::3",
>>>> +# "ipv6-prefix": "fec0::",
>>>> +# "net": "10.0.2.0/255.255.255.0",
>>>> +# "ipv6-host": "fec0::2",
>>>> +# "type": "user",
>>>> +# "peer-id": "net0",
>>>> +# "dns": "10.0.2.3",
>>>> +# "hostfwd": [
>>>> +# {
>>>> +# "str": "tcp::20004-:22"
>>>> +# }
>>>> +# ],
>>>> +# "ipv6-prefixlen": 64,
>>>> +# "id": "netdev0",
>>>> +# "restrict": false
>>>> +# }
>>>> +# ]
>>>> +# }
>>>> +#
>>>> +##
>>>> +{ 'command': 'query-netdevs', 'returns': ['NetdevInfo'] }
--
Alexey Kirillov
Yandex.Cloud
next prev parent reply other threads:[~2020-09-08 15:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-01 18:23 [PATCH v3 0/4] Introducing QMP query-netdevs command Alexey Kirillov
2020-09-01 18:23 ` [PATCH v3 1/4] qapi: net: Add " Alexey Kirillov
2020-09-02 11:23 ` Markus Armbruster
2020-09-07 10:37 ` Alexey Kirillov
2020-09-07 12:39 ` Markus Armbruster
2020-09-08 12:36 ` Eric Blake
2020-09-08 14:31 ` Markus Armbruster
2020-09-16 9:37 ` Alexey Kirillov
2020-09-16 11:28 ` Markus Armbruster
2020-09-08 15:52 ` Alexey Kirillov [this message]
2020-09-09 11:41 ` Markus Armbruster
2020-09-09 12:45 ` Alexey Kirillov
2020-09-08 14:29 ` Markus Armbruster
2020-09-08 15:52 ` Alexey Kirillov
2020-09-01 18:23 ` [PATCH v3 2/4] tests: Add tests for " Alexey Kirillov
2020-09-01 18:23 ` [PATCH v3 3/4] hmp: Use QMP query-netdevs in hmp_info_network Alexey Kirillov
2020-09-01 18:23 ` [PATCH v3 4/4] net: Do not use legacy info_str for backends Alexey Kirillov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18211599579782@mail.yandex-team.ru \
--to=lekiravi@yandex-team.ru \
--cc=armbru@redhat.com \
--cc=g.lettieri@iet.unipi.it \
--cc=jasowang@redhat.com \
--cc=lvivier@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rizzo@iet.unipi.it \
--cc=samuel.thibault@ens-lyon.org \
--cc=sw@weilnetz.de \
--cc=thuth@redhat.com \
--cc=v.maffione@gmail.com \
--cc=yc-core@yandex-team.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).