From: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
To: virtio-dev@lists.oasis-open.org
Cc: jasowang@redhat.com, "Michael S. Tsirkin" <mst@redhat.com>,
Parav Pandit <parav@nvidia.com>,
virtio-comment@lists.oasis-open.org
Subject: [virtio-comment] [RFC] virtio-net: support access and control the member devices
Date: Thu, 3 Aug 2023 16:31:50 +0800 [thread overview]
Message-ID: <20230803083150.46745-1-xuanzhuo@linux.alibaba.com> (raw)
Now we have the concept of the device group. This allows us to
support sr-iov and siov more conveniently.
The following description uses pf, vf as an example. The scene with sf
should be similar.
According to my understanding, the management at the level of virtqueue
should be handled by admin queue. And the net related management is
still managed by cvq of pf. So this patch works with the cvq of the pf.
The problem I am trying to solve is when there are multiple vf
virtio-net devices under one pf.
It is necessary for administrators to query the status and information
of each vf and configure mac.
Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
---
device-types/net/description.tex | 72 +++++++++++++++++++++++--
device-types/net/device-conformance.tex | 1 +
2 files changed, 70 insertions(+), 3 deletions(-)
diff --git a/device-types/net/description.tex b/device-types/net/description.tex
index 76585b0..1494a18 100644
--- a/device-types/net/description.tex
+++ b/device-types/net/description.tex
@@ -88,6 +88,9 @@ \subsection{Feature bits}\label{sec:Device Types / Network Device / Feature bits
\item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
channel.
+\item[VIRTIO_NET_F_ACCESS_MEMBER_DEVICE(51)] Device can access and control the
+ member devices.
+
\item[VIRTIO_NET_F_HASH_TUNNEL(51)] Device supports inner header hash for encapsulated packets.
\item[VIRTIO_NET_F_VQ_NOTF_COAL(52)] Device supports virtqueue notification coalescing.
@@ -1156,6 +1159,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
u8 command;
u8 command-specific-data[];
u8 ack;
+ u8 command-specific-data-reply[];
};
/* ack values */
@@ -1164,9 +1168,11 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
\end{lstlisting}
The \field{class}, \field{command} and command-specific-data are set by the
-driver, and the device sets the \field{ack} byte. There is little it can
-do except issue a diagnostic if \field{ack} is not
-VIRTIO_NET_OK.
+driver, and the device sets the \field{ack} byte and optionally
+\field{command-specific-data-reply}. There is little the driver can
+do except issue a diagnostic if \field{ack} is not VIRTIO_NET_OK.
+
+The command VIRTIO_NET_CTRL_MEMBER_GET_INFO contains \field{command-specific-data-reply}.
\paragraph{Packet Receive Filtering}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Setting Promiscuous Mode}%old label for latexdiff
@@ -1805,6 +1811,66 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
Upon reset, a device MUST initialize all coalescing parameters to 0.
+\paragraph{Member Device}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Member Info}
+
+If a deivce is the own deivce inside one device group and the feature
+VIRTIO_NET_F_ACCESS_MEMBER_DEVICE is negotiated, the own driver can obtain
+the info and change the configuration of the member devices of this device
+group.
+
+\begin{lstlisting}
+struct virtio_net_ctrl_member {
+ le64 group_member_id;
+};
+
+struct virtio_net_ctrl_member_info_reply {
+ u8 mac[6];
+ le16 status;
+ le16 max_virtqueue_pairs;
+ le16 mtu;
+ le32 speed;
+ u8 duplex;
+ u8 driver_ok;
+ le16 current_virtqueue_pairs;
+};
+
+struct virtio_net_ctrl_member_set_mac {
+ le64 group_member_id;
+ u8 mac[6];
+};
+
+#define VIRTIO_NET_CTRL_MEMBER 7
+ #define VIRTIO_NET_CTRL_MEMBER_GET_INFO 0
+ #define VIRTIO_NET_CTRL_MEMBER_SET_MAC 1
+\end{lstlisting}
+
+\devicenormative{\subparagraph}{Member Device}{Device Types / Network Device / Device Operation / Control Virtqueue / Member Device}
+
+The device only offers the feature VIRTIO_NET_F_ACCESS_MEMBER_DEVICE when it is
+the own device.
+
+If the \field{group_member_id} is not within the range of the member device id,
+the own device MUST respond with VIRTIO_NET_ERR.
+
+struct virtio_net_ctrl_member_info_reply is used to reply the command
+VIRTIO_NET_CTRL_MEMBER_GET_INFO via \field{command-specific-data-reply}.
+
+If the member device specified by the \field{group_member_id} is in the
+DRIVER_OK status, the own device MUST set the \field{driver_ok} to 1 and set the
+\field{current_virtqueue_pairs} to the number of virtqueue pairs that are being
+used by the member device. Otherwise, both \field{driver_ok} and
+\field{current_virtqueue_pairs} MUST be set to zero.
+
+All other fields of the struct virtio_net_ctrl_member_info_reply MUST be equal
+to the values in the struct virtio_net_config of the member device.
+
+If the member device specified by the \field{group_member_id} supports
+VIRTIO_NET_F_MAC and its status is not DRIVER_OK, the own device MUST reply to
+VIRTIO_NET_CTRL_MEMBER_SET_MAC with VIRTIO_NET_OK, and the member device MUST
+offer the \field{mac} to the member driver via the struct virtio_net_config.
+Otherwise, the own device MUST reply to the command
+VIRTIO_NET_CTRL_MEMBER_SET_MAC with VIRTIO_NET_ERR.
+
\subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
Types / Network Device / Legacy Interface: Framing Requirements}
diff --git a/device-types/net/device-conformance.tex b/device-types/net/device-conformance.tex
index f88f48b..9af3293 100644
--- a/device-types/net/device-conformance.tex
+++ b/device-types/net/device-conformance.tex
@@ -15,4 +15,5 @@
\item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing}
\item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Notifications Coalescing}
\item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Inner Header Hash}
+\item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Member Device}
\end{itemize}
--
2.32.0.3.g01195cf9f
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
next reply other threads:[~2023-08-03 8:31 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-03 8:31 Xuan Zhuo [this message]
2023-08-03 9:44 ` [virtio-comment] Re: [RFC] virtio-net: support access and control the member devices Michael S. Tsirkin
2023-08-03 9:45 ` [virtio-comment] " Parav Pandit
2023-08-03 10:52 ` [virtio-comment] " Xuan Zhuo
2023-08-03 10:59 ` [virtio-comment] " Parav Pandit
2023-08-03 11:04 ` [virtio-comment] " Xuan Zhuo
2023-08-03 11:15 ` [virtio-comment] " Parav Pandit
2023-08-03 11:18 ` [virtio-comment] " Xuan Zhuo
2023-08-03 11:25 ` [virtio-comment] " Parav Pandit
2023-08-03 11:30 ` [virtio-comment] " Xuan Zhuo
2023-08-03 11:39 ` [virtio-comment] " Parav Pandit
2023-08-03 11:41 ` Xuan Zhuo
2023-08-03 13:15 ` Parav Pandit
2023-08-03 17:03 ` Satananda Burla
2023-08-04 3:29 ` Jason Wang
2023-08-04 4:22 ` Parav Pandit
2023-08-04 6:18 ` Xuan Zhuo
2023-08-04 6:37 ` Parav Pandit
2023-08-04 6:54 ` Xuan Zhuo
2023-08-04 7:26 ` Parav Pandit
2023-08-04 7:44 ` Xuan Zhuo
2023-08-04 10:33 ` Michael S. Tsirkin
2023-08-04 12:49 ` Parav Pandit
2023-08-04 14:07 ` Michael S. Tsirkin
2023-08-04 14:12 ` Parav Pandit
2023-08-06 10:32 ` Michael S. Tsirkin
2023-08-07 6:02 ` Xuan Zhuo
2023-08-08 2:18 ` Jason Wang
2023-08-08 2:36 ` Xuan Zhuo
2023-08-08 3:09 ` Jason Wang
2023-08-08 3:13 ` Xuan Zhuo
2023-08-08 3:16 ` Parav Pandit
2023-08-08 3:50 ` Jason Wang
2023-08-08 4:16 ` Parav Pandit
2023-08-08 4:33 ` Jason Wang
2023-08-08 4:37 ` Parav Pandit
2023-08-08 5:21 ` Jason Wang
2023-08-08 6:16 ` Xuan Zhuo
2023-08-08 6:44 ` Xuan Zhuo
2023-08-08 6:56 ` Parav Pandit
2023-08-08 4:00 ` Xuan Zhuo
2023-08-08 4:11 ` Parav Pandit
2023-08-08 4:16 ` Xuan Zhuo
2023-08-08 4:34 ` Parav Pandit
2023-08-08 6:02 ` Xuan Zhuo
2023-08-08 4:18 ` Satananda Burla
2023-08-04 3:31 ` [virtio-comment] " Jason Wang
2023-08-04 4:05 ` [virtio-comment] " Parav Pandit
2023-08-08 2:30 ` [virtio-comment] " Jason Wang
2023-08-03 10:23 ` [virtio-comment] " Parav Pandit
2023-08-03 11:05 ` [virtio-comment] " Xuan Zhuo
2023-08-03 11:13 ` [virtio-comment] " Parav Pandit
2023-08-03 11:15 ` [virtio-comment] " Xuan Zhuo
2023-08-03 11:21 ` [virtio-comment] " Parav Pandit
2023-08-03 11:27 ` [virtio-comment] " Xuan Zhuo
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=20230803083150.46745-1-xuanzhuo@linux.alibaba.com \
--to=xuanzhuo@linux.alibaba.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=parav@nvidia.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).