From: "Michael S. Tsirkin" <mst@redhat.com>
To: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: virtio-dev@lists.oasis-open.org, jasowang@redhat.com,
Parav Pandit <parav@nvidia.com>,
virtio-comment@lists.oasis-open.org
Subject: [virtio-dev] Re: [RFC] virtio-net: support access and control the member devices
Date: Thu, 3 Aug 2023 05:44:23 -0400 [thread overview]
Message-ID: <20230803054333-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20230803083150.46745-1-xuanzhuo@linux.alibaba.com>
On Thu, Aug 03, 2023 at 04:31:50PM +0800, Xuan Zhuo wrote:
> 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>
I think we should use admin queue for this, and not cvq.
> ---
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2023-08-03 9:44 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-03 8:31 [virtio-dev] [RFC] virtio-net: support access and control the member devices Xuan Zhuo
2023-08-03 9:44 ` Michael S. Tsirkin [this message]
2023-08-03 9:45 ` [virtio-dev] " Parav Pandit
2023-08-03 10:52 ` [virtio-dev] " Xuan Zhuo
2023-08-03 10:59 ` [virtio-dev] " Parav Pandit
2023-08-03 11:04 ` [virtio-dev] " Xuan Zhuo
2023-08-03 11:15 ` [virtio-dev] " Parav Pandit
2023-08-03 11:18 ` [virtio-dev] " Xuan Zhuo
2023-08-03 11:25 ` [virtio-dev] " Parav Pandit
2023-08-03 11:30 ` [virtio-dev] " Xuan Zhuo
2023-08-03 11:39 ` [virtio-dev] " Parav Pandit
2023-08-03 11:41 ` [virtio-dev] Re: [virtio-comment] " Xuan Zhuo
2023-08-03 13:15 ` [virtio-dev] " Parav Pandit
2023-08-03 17:03 ` Satananda Burla
2023-08-04 3:29 ` [virtio-dev] " Jason Wang
2023-08-04 4:22 ` [virtio-dev] " Parav Pandit
2023-08-04 6:18 ` [virtio-dev] " Xuan Zhuo
2023-08-04 6:37 ` [virtio-dev] " Parav Pandit
2023-08-04 6:54 ` [virtio-dev] " Xuan Zhuo
2023-08-04 7:26 ` [virtio-dev] " Parav Pandit
2023-08-04 7:44 ` [virtio-dev] " Xuan Zhuo
2023-08-04 10:33 ` Michael S. Tsirkin
2023-08-04 12:49 ` [virtio-dev] " Parav Pandit
2023-08-04 14:07 ` [virtio-dev] " Michael S. Tsirkin
2023-08-04 14:12 ` [virtio-dev] " Parav Pandit
2023-08-06 10:32 ` [virtio-dev] " Michael S. Tsirkin
2023-08-07 6:02 ` [virtio-dev] Re: " 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 ` [virtio-dev] " Parav Pandit
2023-08-08 3:50 ` [virtio-dev] " Jason Wang
2023-08-08 4:16 ` [virtio-dev] " Parav Pandit
2023-08-08 4:33 ` [virtio-dev] " Jason Wang
2023-08-08 4:37 ` [virtio-dev] " Parav Pandit
2023-08-08 5:21 ` [virtio-dev] " Jason Wang
2023-08-08 6:16 ` Xuan Zhuo
2023-08-08 6:44 ` [virtio-dev] Re: " Xuan Zhuo
2023-08-08 6:56 ` [virtio-dev] " Parav Pandit
2023-08-08 4:00 ` [virtio-dev] " Xuan Zhuo
2023-08-08 4:11 ` [virtio-dev] " Parav Pandit
2023-08-08 4:16 ` [virtio-dev] " Xuan Zhuo
2023-08-08 4:34 ` [virtio-dev] " Parav Pandit
2023-08-08 6:02 ` [virtio-dev] " Xuan Zhuo
2023-08-08 4:18 ` [virtio-dev] " Satananda Burla
2023-08-04 3:31 ` [virtio-dev] " Jason Wang
2023-08-04 4:05 ` [virtio-dev] " Parav Pandit
2023-08-08 2:30 ` [virtio-dev] " Jason Wang
2023-08-03 10:23 ` [virtio-dev] " Parav Pandit
2023-08-03 11:05 ` [virtio-dev] " Xuan Zhuo
2023-08-03 11:13 ` [virtio-dev] " Parav Pandit
2023-08-03 11:15 ` [virtio-dev] " Xuan Zhuo
2023-08-03 11:21 ` [virtio-dev] " Parav Pandit
2023-08-03 11:27 ` [virtio-dev] " 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=20230803054333-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=jasowang@redhat.com \
--cc=parav@nvidia.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=xuanzhuo@linux.alibaba.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