public inbox for virtio-dev@lists.linux.dev
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: virtio-comment@lists.oasis-open.org,
	virtio-dev@lists.oasis-open.org, parav@nvidia.com
Subject: [virtio-dev] Re: [RFC PATCH] admin-queue: bind the group member to the device
Date: Mon, 26 Jun 2023 05:32:47 -0400	[thread overview]
Message-ID: <20230626031704-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20230626062210.49020-1-xuanzhuo@linux.alibaba.com>

On Mon, Jun 26, 2023 at 02:22:10PM +0800, Xuan Zhuo wrote:
> The VFs of the SR-IOV are created by the user inside the guest OS, so the virtio
> devices don't know about these VFs. Because each VF may be assigned a different role
> by the user, the virtio device can not choose one VF to bind random.
> So only the user knows how to bind the virtio devices to the VFs.
> On the other hand, generally the virtio devices are not created by the user
> inside the guest OS. This requires some management platform to participate.
> 
> So the usage of this command:
> 1. The user purchases a virtio network card on the management platform,
>    and sets the ip, queue number, etc. The user obtains the identity of
>    the network card.
> 2. The user creates a VF with echo 8 > sriov_numvfs

this one is unlikely, as this requires PF access and affects all VFs.

> 3. The user binds the net crad to a VF with identity through the command
>    of the patch
> 
> Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>




> ---
>  admin.tex | 41 ++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 40 insertions(+), 1 deletion(-)
> 
> diff --git a/admin.tex b/admin.tex
> index 2efd4d7..64d0667 100644
> --- a/admin.tex
> +++ b/admin.tex
> @@ -115,7 +115,8 @@ \subsection{Group administration commands}\label{sec:Basic Facilities of a Virti
>  \hline \hline
>  0x0000 & VIRTIO_ADMIN_CMD_LIST_QUERY & Provides to driver list of commands supported for this group type    \\
>  0x0001 & VIRTIO_ADMIN_CMD_LIST_USE & Provides to device list of commands used for this group type \\
> -0x0002 - 0x7FFF & - & Commands using \field{struct virtio_admin_cmd}    \\
> +0x0002 & VIRTIO_ADMIN_CMD_BIND_DEVICE & Bind the device to one group member \\
> +0x0003 - 0x7FFF & - & Commands using \field{struct virtio_admin_cmd}    \\
>  \hline
>  0x8000 - 0xFFFF & - & Reserved for future commands (possibly using a different structure)    \\
>  \hline
> @@ -429,6 +430,44 @@ \subsection{Group administration commands}\label{sec:Basic Facilities of a Virti
>  \field{VF Enable} refer to registers within the SR-IOV Extended
>  Capability as specified by \hyperref[intro:PCIe]{[PCIe]}.
>  
> +\subsubsection{Bind the device for member}
> +
> +The VFs of the SR-IOV are created by the user inside the guest OS, so the virtio
> +devices don't know about these VFs.

I don't really get how.

> Because each VF may be assigned a different role
> +by the user, the virtio device can not choose one VF to bind random.
> +So only the user knows how to bind the virtio devices to the VFs.
> +On the other hand, generally the virtio devices are not created by the user
> +inside the guest OS. This requires some management platform to participate.
> +
> +So we introduce a new admin queue command to bind the VFs and the virtio
> +devices.

This description needs a complete rewrite, but to try to help you I'd
need to figure out what is being said. My guess is that this is an
attempt to introduce some kind of identity to VFs.  OK but what is this
identity and how is it better than using VF#?  You want it to persist
when NumVFs in the SR-IOV capability changes?

> +\begin{lstlisting}
> +struct virtio_admin_cmd_bind {
> +    u64 identity;
> +};
> +\end{lstlisting}
> +
> +The user got the \field{identity} from the management platform, that is not
> +included by this spec.

Without even understanding the above, what I don't like about this
proposal, is that it assumes some out of band interface to either
specify or discover these IDs. With admin commands we now have
ability to fully specify a management interface, and I'd rather
we had a complete proposal covering all aspects of it.
If some platform does not want to use the management aspects,
that's ok.

> +
> +\drivernormative{\paragraph}{Group administration commands}{Basic Facilities of a Virtio Device / Device groups / Group administration commands / Bind the device for member}
> +
> +VIRTIO_ADMIN_CMD_BIND_DEVICE requires that the \field{group_member_id} MUST be set.
> +
> +The \field{identity} is passed by the user. It is the identity of the virtio
> +device.
> +
> +\devicenormative{\paragraph}{Group administration commands}{Basic Facilities of a Virtio Device / Device groups / Group administration commands / Bind the device for member}
> +
> +Every device MUST have one unique \field{identity} in the host.
> +
> +If the PF device can not find the device by the \field{identity},
> +the \field{status} MUST be set to VIRTIO_ADMIN_STATUS_EINVAL.
> +
> +If the device is found by the \field{identity}, the device MUST work as the
> +device of this group member specified by the \field{group_member_id}.
> +
>  \section{Administration Virtqueues}\label{sec:Basic Facilities of a Virtio Device / Administration Virtqueues}
>  
>  An administration virtqueue of an owner device is used to submit

> -- 
> 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


  parent reply	other threads:[~2023-06-26  9:33 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-26  6:22 [virtio-dev] [RFC PATCH] admin-queue: bind the group member to the device Xuan Zhuo
2023-06-26  6:43 ` [virtio-dev] Re: [virtio-comment] " Zhu, Lingshan
2023-06-26  7:08   ` Xuan Zhuo
2023-06-26  7:57     ` Zhu, Lingshan
2023-06-26  8:09       ` Xuan Zhuo
2023-06-26  8:59         ` Zhu, Lingshan
2023-06-26  9:16           ` Xuan Zhuo
2023-06-26  9:32             ` [virtio-dev] Re: [virtio-comment] " Xuan Zhuo
2023-06-26  9:56             ` Zhu, Lingshan
2023-06-26 10:50               ` Xuan Zhuo
2023-06-26 12:19                 ` [virtio-dev] " Parav Pandit
2023-06-26 12:32                   ` [virtio-dev] " Xuan Zhuo
2023-06-26 13:01                     ` [virtio-dev] " Parav Pandit
2023-06-26 12:35                   ` [virtio-dev] " Michael S. Tsirkin
2023-06-26 12:39                     ` Xuan Zhuo
2023-06-26 22:46                     ` [virtio-dev] " Parav Pandit
2023-06-27  2:57                 ` [virtio-dev] " Zhu, Lingshan
2023-06-27  8:14                   ` Xuan Zhuo
2023-06-27  9:04                     ` Zhu, Lingshan
2023-06-26  9:32 ` Michael S. Tsirkin [this message]
2023-06-26  9:35   ` [virtio-dev] Re: [virtio-comment] " Xuan Zhuo
2023-06-27  8:08 ` [virtio-dev] Re: [virtio-comment] " Jason Wang
2023-06-27  8:16   ` Xuan Zhuo
2023-06-27  8:23 ` Xuan Zhuo
2023-06-27  9:00   ` Jason Wang
2023-06-27 10:50     ` Xuan Zhuo
2023-06-28  2:49       ` Jason Wang
2023-06-28  6:06         ` Xuan Zhuo
2023-06-28 15:55           ` Michael S. Tsirkin
2023-06-29  3:29             ` Jason Wang
2023-06-27 15:03   ` [virtio-dev] " Parav Pandit
2023-06-27 16:02   ` [virtio-dev] " Michael S. Tsirkin
2023-06-28  2:21     ` Xuan Zhuo
2023-06-28 15:06       ` [virtio-dev] " Parav Pandit
2023-06-28 15:41       ` [virtio-dev] " Michael S. Tsirkin
2023-07-03  3:21         ` Xuan Zhuo
2023-07-03  7:42           ` Jason Wang
2023-07-03 20:03           ` Parav Pandit

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=20230626031704-mutt-send-email-mst@kernel.org \
    --to=mst@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