From: huangy81@chinatelecom.cn
To: qemu-devel <qemu-devel@nongnu.org>
Cc: "Michael S . Tsirkin" <mst@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"Eric Blake" <eblake@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Laurent Vivier" <lvivier@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Stefano Garzarella" <sgarzare@redhat.com>,
"Raphael Norwitz" <raphael.norwitz@nutanix.com>,
"Hyman Huang(黄勇)" <huangy81@chinatelecom.cn>
Subject: [PATCH RFC 0/4] Export netdev capabilities and information
Date: Tue, 1 Nov 2022 00:18:58 +0800 [thread overview]
Message-ID: <cover.1667232396.git.huangy81@chinatelecom.cn> (raw)
From: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
This series is enlightened by Michael when we fixed a virtio features
negotiation flaw, see the details here:
https://lore.kernel.org/qemu-devel/cover.1667136717.git.huangy81@chinatelecom.cn/
And a test is suggested to be added to test behavior of virtio-net features
negotiation(if i understand correctly), see the details here:
https://lore.kernel.org/qemu-devel/20221026105516-mutt-send-email-mst@kernel.org/
Indeed, Qemu does not export interface capabilities such as ufo, vnet-hdr or
negotiated features to developers. OVS-DPDK will show the interface status such
as features, mode, ring_size and so on if we execute "ovs-vsctl list interface"
by comparison. It could be more friendly if we export above capabilities and
information for developers, especially for those who devote to offload virtio-net
dataplane to DPU and make efforts to migrate vm lively from software-based source
to DPU-offload destination smoothly, virtio-net feature compatibility is an
serious issue, exporting the key capability and acked_features of netdev could
help to debug greatly.
This series export out the key capabilities of netdev, which may affect the final
negotiated virtio-net features, meanwhile, backed-up acked_features also exported,
which is used to initialize or restore features negotiated between qemu and vhost
slave when starting vhost_dev device.
Another thing the patchset did is adding a virtio-net features check test, which
use the fresh new qmp interface "query-netdev" to check if features are
negotiated correctly via vhost user protocol.
This patchset depends on the previous patchset which is in the process of code
reviewing. So this post aims to request for comments as the subject say, any
suggestions and comments are welcome and i would appreciate a lot.
Please review, thanks,
Hyman Huang (4):
net: Introduce qmp cmd "query-netdev"
hmp: Add "info netdev" cmd
hmp: Add netdev information into output of hmp cmd "info network"
vhost-user-test: Add negotiated features check
hmp-commands-info.hx | 14 +++++++
include/monitor/hmp.h | 1 +
net/net.c | 90 +++++++++++++++++++++++++++++++++++++++++++
qapi/net.json | 66 +++++++++++++++++++++++++++++++
tests/qtest/vhost-user-test.c | 67 ++++++++++++++++++++++++++++++++
5 files changed, 238 insertions(+)
--
1.8.3.1
next reply other threads:[~2022-10-31 16:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-31 16:18 huangy81 [this message]
2022-10-31 16:18 ` [PATCH RFC 1/4] net: Introduce qmp cmd "query-netdev" huangy81
2022-11-02 5:42 ` Jason Wang
2022-11-02 6:41 ` Michael S. Tsirkin
2022-11-02 15:36 ` Hyman
2022-11-02 7:10 ` Thomas Huth
2022-11-02 15:37 ` Hyman
2022-11-02 15:31 ` Hyman
2022-10-31 16:19 ` [PATCH RFC 2/4] hmp: Add "info netdev" cmd huangy81
2022-11-02 7:13 ` Thomas Huth
2022-10-31 16:19 ` [PATCH RFC 3/4] hmp: Add netdev information into output of hmp cmd "info network" huangy81
2022-10-31 16:19 ` [PATCH RFC 4/4] vhost-user-test: Add negotiated features check huangy81
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=cover.1667232396.git.huangy81@chinatelecom.cn \
--to=huangy81@chinatelecom.cn \
--cc=armbru@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=jasowang@redhat.com \
--cc=lvivier@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=raphael.norwitz@nutanix.com \
--cc=sgarzare@redhat.com \
--cc=thuth@redhat.com \
/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).