OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-comment] [PATCH] virtio-net: introduce admin control virtqueue



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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]