All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: virtio-comment@lists.oasis-open.org, mst@redhat.com
Subject: Re: [virtio-comment] [PATCH] virtio-net: introduce admin control virtqueue
Date: Sun, 24 Jan 2021 23:08:08 -0500 (EST)	[thread overview]
Message-ID: <1136488155.49478472.1611547688847.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <cda56ec7-27dd-3c0d-ac7d-814a01512ff1@redhat.com>



----- Original Message -----
> 
> On 2021/1/22 下午6:11, Cornelia Huck wrote:
> > On Fri, 22 Jan 2021 16:23:25 +0800
> > Jason Wang<jasowang@redhat.com>  wrote:
> >
> >> When implementing multiple (sub)functions virtio device like SRIOV or
> >> sub-function. We're suffering from several issues:
> >>
> >> - There's no management interface for management function (PF) to
> >>    configure features, attributes for a (sub)function
> >> - Per (sub)function control virtqueue could be too expensive as the
> >>    number of (sub)functions could be very large
> >> - Virtualize per (sub)function control virtqueue could be very
> >>    challenge as we need the support of DMA isolation at queue level
> >>
> >> So this patch introduces the feature of VIRTIO_NET_CTRL_ADMIN_VQ. This
> >> allows the device to implement a single admin control virtqueue to
> >> manage per (sub)function features and attributes.
> >>
> >> The idea is simple, a new function id is introduced on top of the
> >> exist virtio_net_ctrl structure. This id is transport or device
> >> specific to uniquely identify a (sub)function.
> >>
> >> With this, we get a way of using management function (PF) to configure
> >> per (sub)function features and attributes. And since the admin control
> >> virtqueue belongs to management function (PF), the DMA is naturally
> >> isolated at (sub)function level instead of the queue level for per
> >> (sub)function control vq.
> >>
> >> Signed-off-by: Jason Wang<jasowang@redhat.com>
> >> ---
> >>   content.tex | 23 +++++++++++++++++++++++
> >>   1 file changed, 23 insertions(+)
> >>
> >> diff --git a/content.tex b/content.tex
> >> index 620c0e2..98592a4 100644
> >> --- a/content.tex
> >> +++ b/content.tex
> >> @@ -2940,6 +2940,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_ADMIN_CTRL_VQ(56)] Admin control channel is
> >> +    available.
> >> +
> >>   \item[VIRTIO_NET_F_HASH_REPORT(57)] Device can report per-packet hash
> >>       value and a type of calculated hash.
> >>   
> >> @@ -3864,6 +3867,26 @@ \subsubsection{Control Virtqueue}\label{sec:Device
> >> Types / Network Device / Devi
> >>   do except issue a diagnostic if \field{ack} is not
> >>   VIRTIO_NET_OK.
> >>   
> >> +\subsubsection{Admin Control Virtqueue}\label{sec:Device Types / Network
> >> Device / Device Operation / Control Virtqueue}
> >> +
> >> +When VIRTIO_NET_F_ADMIN_CTRL_VQ is negotiated, the driver can use the
> >> +control virtqueue to manipulate features of individual function where
> >> +the control virtqueues is not easily implemented in each function.
> > What is a 'function' in the context of the virtio-net device? I don't
> > think that this term is universal across transports.
> 
> 
> Good point. It might have well definition only in PCI.
> 
> I wonder whether we can use "virtual device" here? It avoids transport
> specific terminology. And we can explain "virtual device" in one or two
> sentences here.
> 
> Thanks


Something like:

When VIRTIO_NET_F_ADMIN_CTRL_VQ is negotiated, the driver can use the
admin control virtqueue of the management device to manipulate
features of individual virtual devices where the control virtqueue is
not easily implemented. The definition of management device and
virtual device is totally transport specific. E.g in the case of PCI
transport, the management device is usually the physical function (PF),
and the virtual device is the virtual function (VF).

Thanks

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


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/


      reply	other threads:[~2021-01-25  4:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-22  8:23 [virtio-comment] [PATCH] virtio-net: introduce admin control virtqueue Jason Wang
2021-01-22  8:31 ` [virtio-comment] " Michael S. Tsirkin
2021-01-22  8:41   ` Jason Wang
2021-01-22  9:03     ` Michael S. Tsirkin
2021-01-22  9:14       ` Jason Wang
2021-01-22 12:14         ` Michael S. Tsirkin
2021-01-25  3:57           ` Jason Wang
2021-01-22 10:11 ` [virtio-comment] " Cornelia Huck
2021-01-25  3:51   ` Jason Wang
2021-01-25  4:08     ` Jason Wang [this message]

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=1136488155.49478472.1611547688847.JavaMail.zimbra@redhat.com \
    --to=jasowang@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=mst@redhat.com \
    --cc=virtio-comment@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.