[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] [PATCH V2] virtio-net: introduce admin control virtqueue
On 2021/2/1 äå11:49, Cornelia Huck wrote:
On Mon, 1 Feb 2021 12:09:15 +0800 Jason Wang <jasowang@redhat.com> wrote:On 2021/1/30 äå6:48, Halil Pasic wrote:On Mon, 25 Jan 2021 13:52:02 +0800 Jason Wang <jasowang@redhat.com> wrote:@@ -3840,11 +3843,12 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue}The driver uses the control virtqueue (if VIRTIO_NET_F_CTRL_VQ is-negotiated) to send commands to manipulate various features of -the device which would not easily map into the configuration -space. +negotiated but VIRTIO_NET_F_ADMIN_CTRL_VQ is not negotiated) to send +commands to manipulate various features of the device which would not +easily map into the configuration space.Let's assume device offers both VIRTIO_NET_F_ADMIN_CTRL_VQ and VIRTIO_NET_F_CTRL_VQ, but driver accepts only VIRTIO_NET_F_CTRL_VQ, because it is an old driver that only knows about VIRTIO_NET_F_CTRL_VQ. What happens then? Do we expect the control queue virtqueue to just work?I think the answer is yes, my understanding is that it's better to provide backward compatibility for the old drivers.I agree, I'd expect the device to just use the CTRL_VQ semantics, or fail feature negotiation.I read the proposal like VIRTIO_NET_F_ADMIN_CTRL_VQ and VIRTIO_NET_F_CTRL_VQ are mutually exclusive features, and not stacking features, but my confidence in this regard is very low. If they are mutually exclusive, we should make the feature bits mutually exclusive as well.It works like: If VIRTIO_NET_F_CTRL_VQ is negotiated but not VIRTIO_NET_F_ADMIN_CTRL_VQ, the control virtqueue will use the old command format. If both are negotiated, the control virtqueue will use the new format.What if ADMIN_CTRL_VQ is negotiated, but not CTRL_VQ? I assume that this is an invalid combination that should not be accepted?
Yes, I will clarify this in the next version.
(...)+All commands are of the following form: + +\begin{lstlisting} +struct virtio_net_admin_ctrl { + u32 virtual_device_id; + struct virtio_net_ctrl ctrl; +}; +\end{lstlisting} + +The \field{virtual_device_id} is an unique transport or device specific +identifier for a virtual device or management device. E.g for the case +of PCI SR-IOV, it's the PCI function id. Management device MUST +reserve 0 for \field{virtual_device_id} to identify itself. +How is a portable driver supposed to obtain this transport or device specific ID?Good question. The idea is: 1) if we had transport specific feature like VIRTIO_F_SR_IOV, the id is simply PCI function id 2) if virtio support it's own IOV feature (that is mutually exclusive with the transport specific one), the id must be obtained via a virtio method. For 2) I plan to introduce a general admin virtqueue that is used for virtio specific device IOV. In that implementation, the virtual device must be created and destroyed via admin virtqueue. During device creation a unique ID is needed then the driver should know/allocate the id in advance.Let me elaborate. Let's say I'm a guest and I happen to have a virtio-net device, which ain't capable doing the usual controlq stuff via the usual controlq, so I have to use this new mechanism (if I, for example, want to set the MAC address for it. To do so, I need to know the virtual_device_id of my virtual virtio-net device, to be able to put it in my virtio_net_admin_ctl command, and that command I need to put into some admin control virtqueue. The paragraph above suggests, that this virtqueue is not the controlq of my virtual virtio-net device I'm trying to control, but a virtqueue that belongs to the management device. Obviously for a non-PCI device, it ain't making no sense to define this device id as the PCI function id. I guess, this is where the 'transport specific' comes from. But then shouldn't we define the transport specific part in a transport specific section?I think we need keep the general format here but maybe we can add a reference to the transport specific part that describe the id in detail.Also please notice, that the structure virtio_net_admin_ctrl is defined in the transport agnostic part, that is it has to work for any transport. Which implies that any other transport must use ids that fit 32 bits.Yes, if it's not sufficient, I will increase it to 64 bits.Should we maybe use the generic uuid format to identify the device in the commands?
Right, will do. 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]