[virtio-dev] virtio-media-source for cloud native workloads?
Hi, In my last survey of assigned device numbers I went through all the currently assigned device numbers and attempted to glean their current status. However we currently don't have any devices that might be useful in a Cloud Native development environment. To define terms cloud native is the idea you can build a workload processing element as a VM and run it in the cloud. It consumes data from virtio-devices and processes it in someway. This VM can then be moved from being hosted in the cloud and into a real platform which still provides it's data via a virtio device. The idea being you get the same behaviour (as well as allowing for data to be recorded so future debugging/tuning work can be done in the cloud). Currently most of the virtio devices are actually data sinks - for example for virtio-video the guest pushes data to the video device for it to process. What we need is a device(s?) to be a source of data to feed to these workloads. Why virtio-media-source? Well rather than creating a device for every data type maybe it would make more sense to have a generic device which can advertise the data stream info in it's configuration space. This would allow the kernel driver to then route the data to the appropriate kernel subsystem (e.g. v4l or alsa). Would having a virtio driver potentially feeding different sub-systems based on configuration be a problem? What do people think? -- Alex Bennée - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [virtio-comment] RE: [PATCH v5 2/7] Introduce admin command set
On Mon, Jun 20, 2022 at 7:06 PM Parav Pandit wrote: > > > > > From: Michael S. Tsirkin > > Sent: Monday, June 20, 2022 6:00 AM > > > > On Tue, May 31, 2022 at 08:39:24PM +, Parav Pandit wrote: > > > > And as I said, you will need much more spec work to reach the level > > > > to which features are specified - and note we are not yet happy with > > > > how features are > > > Can you be specific of the work that you are expecting in this v5 version? > > > > I proposed getting rid of attrs_mask/device_admin_caps and instead specify > > that e.g. feature bits 64 to 95 are reserved for management purposes. > > Maybe just add a 32 bit register, or maybe "extended features" > > with a selector and length like mmio and ccw already do, up to you. > > I think Cornelia likes this suggestion too. > > > > This would replace functionality of the > > VIRTIO_ADMIN_DEVICE_CAPS_IDENTIFY/VIRTIO_ADMIN_DEVICE_CAPS_AC > > CEPT > > commands and have the advantage of being generally well specified and > > understood. > > > > Is this acceptable? Or is there a reason the new commands are preferable? > > We prefer the new commands for following reason. > > 1. proposed new command doesn't demand exposing registers in the PCI memory > mapped area > 2. Today AQ is perceived in to be PF, but it doesn't have to be. For next 10 > years spec may evolve to have AQ for some other purpose on VFs/SFs. > Such devices scale at much higher magnitude than PFs. > And exposing memory mapped registers for rare functionality is the last thing > to do in my mind. > 3. Placements of such features bits in an AQ gives device lot more > flexibility on _how_ to implement them. Some in sw, fw, hw, memory die etc. > Placement of them in PCI register space reduces these options. > > So exposing them something in PCI register space has to have strong technical > reason than just simplicity of access. I think I know the advantages of admin virtqueue. But this part looks suspicious and actually the reverse, 1) register based transport have been used for years, it's natural to add features based on the existing transport and what you suggest here limit the new features to be carried with those transports 2) admin virtqueue is heavy weight in use cases like nesting, we need a simple interface 3) admin virtqueue is not the universal transport for all cases, we've already had DMA/CMA based transports (e.g ccw and rproc) We'd better decouple features from the transport and allow it to be used by both admin virtqueue and other transports. 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-subscr...@lists.oasis-open.org > Unsubscribe: virtio-comment-unsubscr...@lists.oasis-open.org > List help: virtio-comment-h...@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/ > - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [virtio-comment] RE: [PATCH v5 2/7] Introduce admin command set
On Thu, Jun 23, 2022 at 10:07 AM Parav Pandit wrote: > > > > > From: Jason Wang > > Sent: Wednesday, June 22, 2022 9:27 PM > > > > 1. proposed new command doesn't demand exposing registers in the PCI > > > memory mapped area 2. Today AQ is perceived in to be PF, but it doesn't > > have to be. For next 10 years spec may evolve to have AQ for some other > > purpose on VFs/SFs. > > > Such devices scale at much higher magnitude than PFs. > > > And exposing memory mapped registers for rare functionality is the last > > thing to do in my mind. > > > 3. Placements of such features bits in an AQ gives device lot more > > > flexibility > > on _how_ to implement them. Some in sw, fw, hw, memory die etc. > > > Placement of them in PCI register space reduces these options. > > > > > > So exposing them something in PCI register space has to have strong > > technical reason than just simplicity of access. > > > > I think I know the advantages of admin virtqueue. But this part looks > > suspicious and actually the reverse, > > > > 1) register based transport have been used for years, it's natural to add > > features based on the existing transport and what you suggest here limit the > > new features to be carried with those transports > > 2) admin virtqueue is heavy weight in use cases like nesting, we need a > > simple interface > > 3) admin virtqueue is not the universal transport for all cases, we've > > already > > had DMA/CMA based transports (e.g ccw and rproc) > > > Are you suggesting only feature bits through register-based transport or all > commands via register-based transport? For feature bits, if we don't have admin virtqueue as transport, I suggest it be negotiated with existing transport: we don't need any extension of the existing transport facility to make it work. If we have admin virtqueue as a transport, we must allow the features of the managed device to be negotiated through the admin virtqueue. For other commands, we probably need to analyze it case by case. But if the command is for management only, it should be done via admin virtqueue. (Note that for the MSIX allocation, I do see some vendors allocating it via registers). If the command is used for basic facilities like the virtqueue reset, it should be allowed to be implemented by any transport (admin virtqueue as well as others like PCI registers). Thanks - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [virtio-comment] RE: [PATCH v5 2/7] Introduce admin command set
On Thu, Jun 23, 2022 at 10:57 AM Parav Pandit wrote: > > > > From: Jason Wang > > Sent: Wednesday, June 22, 2022 10:42 PM > > [..] > > > Are you suggesting only feature bits through register-based transport or > > > all > > commands via register-based transport? > > > > For feature bits, if we don't have admin virtqueue as transport, > Right. > Management tasks (features) done via AQ are negotiated via the AQ (regardless > of device type being management dev or managed dev). > It is not replacing usual feature bits negotiation that has strong > relationships with device initialization sequence. Just to clarify, E.g if the admin virtqueue is implemented in PF. I suggest using the existing PCI transport based feature negotiation since: 1) we have selector, so we don't need any new registered and we don't need worry about the scalability 2) the feature negotiated is done once, so we don't need to care about the performance This is the way we used for other features that require a specific type of virtqueue. If we use admin virtqueue (management device) to be a transport for e.g scalable functions (managed devices). We must have a command that is used for feature negotiation for the scalable function (managed devices). > > > I suggest it > > be negotiated with existing transport: we don't need any extension of the > > existing transport facility to make it work. If we have admin virtqueue as a > > transport, we must allow the features of the managed device to be > > negotiated through the admin virtqueue. > > > Regarding above _managed_device_: > > In current version the AQ is on the management device (not managed device). > But AQ as stated is generic to be present on any device that wants to > implement AQ. Yes. > > > For other commands, we probably need to analyze it case by case. But if the > > command is for management only, it should be done via admin virtqueue. > > (Note that for the MSIX allocation, I do see some vendors allocating it via > > registers). > Where do you see it? E.g Intel E810 > In the spec draft? No. Thanks > > > If the command is used for basic facilities like the virtqueue reset, > > it should be allowed to be implemented by any transport (admin virtqueue > > as well as others like PCI registers). - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [PATCH v4] virtio_net: support split header
On Wed, Jun 22, 2022 at 2:08 PM Michael S. Tsirkin wrote:
>
> On Wed, Jun 22, 2022 at 11:52:30AM +0800, Jason Wang wrote:
> >
> > 在 2022/6/21 18:54, Michael S. Tsirkin 写道:
> > > On Mon, Jun 20, 2022 at 11:13:47AM +0800, Xuan Zhuo wrote:
> > > > On Fri, 17 Jun 2022 05:58:11 -0400, "Michael S. Tsirkin"
> > > > wrote:
> > > > > On Fri, Jun 17, 2022 at 03:16:01PM +0800, Xuan Zhuo wrote:
> > > > > > The purpose of this feature is to split the header and the payload
> > > > > > of
> > > > > > the packet.
> > > > > >
> > > > > > |receive buffer
> > > > > >|
> > > > > > | 0th descriptor | 1th descriptor
> > > > > >|
> > > > > > | virtnet hdr | mac | ip hdr | tcp hdr|<-- hold -->| payload
> > > > > >|
> > > > > >
> > > > > > We can use a buffer plus a separate page when allocating the receive
> > > > > > buffer. In this way, we can ensure that all payloads can be
> > > > > > independently in a page, which is very beneficial for the zerocopy
> > > > > > implemented by the upper layer.
> > > > > >
> > > > > > Signed-off-by: Xuan Zhuo
> > > > > > Reviewed-by: Heng Qi
> > > > > > Reviewed-by: Kangjie Xu
> > >
> > > Could you describe the zerocopy in more detail? I'd like to understand
> > > e.g. whether it mixes with mergeable buffers.
> > >
> > > I actually have an idea. Driver could specify an offset from start of
> > > buffer
> > > at which payload is written. This works with mergeable and without,
> >
> >
> > I don't see any difference compared to the current proposal. The only
> > difference is whether or not we should explicit tell the device about the
> > offset.
>
> The current proposal seems to rely on descriptor framing,
> this is using an offset instead.
Yes, but framing is just an implicit specification of the offset (the
length of the first descriptor).
Thanks
>
>
> >
> > > and if header is > offset then flag in packet will simply not be set.
> > > And I think we will want another knob to specify an offset for packets
> > > which can't be split.
> > >
> > > What do you think?
> > >
> > >
> > >
> > > > > > ---
> > > > > > v4:
> > > > > > 1. fix typo @Cornelia Huck @Jason Wang
> > > > > > 2. do not split header for IP fragmentation packet. @Jason Wang
> > > > > >
> > > > > > v3:
> > > > > > 1. Fix some syntax issues
> > > > > > 2. Fix some terminology issues
> > > > > > 3. It is not unified with ip alignment, so ip alignment is not
> > > > > > included
> > > > > > 4. Make it clear that the device must support four types, in
> > > > > > the case of
> > > > > > successful negotiation.
> > > > > >
> > > > > > conformance.tex | 2 ++
> > > > > > content.tex | 88
> > > > > > +
> > > > > > 2 files changed, 90 insertions(+)
> > > > > >
> > > > > > diff --git a/conformance.tex b/conformance.tex
> > > > > > index 663e7c3..6f561fb 100644
> > > > > > --- a/conformance.tex
> > > > > > +++ b/conformance.tex
> > > > > > @@ -149,6 +149,7 @@ \section{Conformance
> > > > > > Targets}\label{sec:Conformance / Conformance Targets}
> > > > > > \item \ref{drivernormative:Device Types / Network Device / Device
> > > > > > Operation / Control Virtqueue / Automatic receive steering in
> > > > > > multiqueue mode}
> > > > > > \item \ref{drivernormative:Device Types / Network Device / Device
> > > > > > Operation / Control Virtqueue / Offloads State Configuration /
> > > > > > Setting Offloads State}
> > > > > > \item \ref{drivernormative:Device Types / Network Device / Device
> > > > > > Operation / Control Virtqueue / Receive-side scaling (RSS) }
> > > > > > +\item \ref{drivernormative:Device Types / Network Device / Device
> > > > > > Operation / Control Virtqueue / Split Header}
> > > > > > \end{itemize}
> > > > > >
> > > > > > \conformance{\subsection}{Block Driver
> > > > > > Conformance}\label{sec:Conformance / Driver Conformance / Block
> > > > > > Driver Conformance}
> > > > > > @@ -411,6 +412,7 @@ \section{Conformance
> > > > > > Targets}\label{sec:Conformance / Conformance Targets}
> > > > > > \item \ref{devicenormative:Device Types / Network Device / Device
> > > > > > Operation / Control Virtqueue / Gratuitous Packet Sending}
> > > > > > \item \ref{devicenormative:Device Types / Network Device / Device
> > > > > > Operation / Control Virtqueue / Automatic receive steering in
> > > > > > multiqueue mode}
> > > > > > \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 / Split Header}
> > > > > > \end{itemize}
> > > > > >
> > > > > > \conformance{\subsection}{Block Device
> > > > > > Conformance}\label{sec:Conformance / Device Conformance / Block
