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] Re: [RFC PATCH v2 1/2] Add virtio Admin Virtqueue specification



å 2021/8/3 äå5:21, Max Gurtovoy åé:

On 8/3/2021 12:01 PM, Jason Wang wrote:

å 2021/8/3 äå4:32, Max Gurtovoy åé:

On 8/3/2021 6:39 AM, Jason Wang wrote:

å 2021/8/2 äå11:27, Max Gurtovoy åé:

On 8/2/2021 5:51 PM, Cornelia Huck wrote:
On Mon, Aug 02 2021, Max Gurtovoy <mgurtovoy@nvidia.com> wrote:

On 8/2/2021 5:17 AM, Jason Wang wrote:
å 2021/8/1 äå6:53, Max Gurtovoy åé:
On 8/1/2021 1:26 AM, Michael S. Tsirkin wrote:
On Sat, Jul 31, 2021 at 02:34:25PM +0300, Max Gurtovoy wrote:
On 7/30/2021 10:05 AM, Cornelia Huck wrote:
On Thu, Jul 29 2021, Max Gurtovoy <mgurtovoy@nvidia.com> wrote:

On 7/28/2021 3:48 PM, Michael S. Tsirkin wrote:
On Mon, Jul 26, 2021 at 07:52:53PM +0300, Max Gurtovoy wrote:
+\subsubsection{Vendor specific command set}\label{sec:Basic
Facilities of a Virtio Device / Admin Virtqueues / Admin
command set / Vendor specific command set}
+
+The Vendor specific command set is a group of classes and
commands
+within each of these classes which are vendor specific. Refer to +each vendor specification for more information on the supported
+commands.
Here's another example.
It's important that there is a way to make a device completely
generic without vendor specific expensions.
Would be hard to do here.

That's a generic comment.

but specifically I am very reluctant to add vendor specific
stuff like
this directly in the spec. We already have
VIRTIO_PCI_CAP_VENDOR_CFG
and if that is not sufficient I would like to know why
before we add more vendor specific stuff.
We are adding an option to add vendor specific commands. We're not adding it to the spec since each vendor will have its own manual for
that.
IMHO, that way madness lies. I want to be able to look at the spec
and
be able to implement a compliant device or a compliant driver. If a vendor has some special feature they want to support, put it in the
spec, so that it is possible to actually implement it.
You can implement a compliant device and a compliant. why do you
think you
can't ?
If I want to implement a device/driver, I need a standard to refer
to. How can something vendor-specific be standard? If it is useful, add
it to the virtio spec.

again, Linux driver will be generic.

It will include a char dev to user space virtio-cli that will enable sending admin commands to do administration.

Nobody asked to add vendor specific code to the driver.


It's not about the general driver but about the general device. We want to present a general standard device which means we can migrate virtio devices among different vendors.

I don't know if it's reasonable.

You're looking on a device as a SW component since it was like this from day 1. But it's not. It's HW, and HW has its own internal state and implementation that is known only to the vendor.


Spec doesn't forbid device internal state. But it cares the state that is visible to the driver. If we had vendor specific state, it would be very hard to claim to be a standard virtio device.





If each vendor choose to implement their own vendor specific features via vendor specific commands that are not ruled by the spec, there will be little value of the spec.

Not at all.

I'm very surprised that you are negative to this RFC instead of working on defining admin commands to stop/start queues and other commands that can be helpful for vDPA migration.


I think there are some misunderstanding here. I'm not negative to admin virtqueue, actually such concept has been discussed by the end of last year. If you search the archive, I've posted RFC for net specific admin virtqueue sometime early this year.

But what I want to be negative is the vendor specific commands/features through the admin virtqueue. The admin virtqueue should be used for general facility like (device stop and migration as you said above).






The spec allows vendor specific stuff today that are not usable and I'm trying to create a usable API without adding one line of vendor code to driver.

You just need to open a window for few commands like others do and like you already did in the spec.

NVIDIA HW internals are different from VENDOR_A and VENDOR_B.

I want to debug my HW or enable some accelerations in it.


A big question is that, on what layer do you want to provide those functions?

1) virtio level
2) vendor level

For 1), it needs to be done in the spec instead of introducing backdoor for vendor specific command

I'm repeating myself. You already have this backdoor for workarounding bugs.


To say the truth, I don't like that. And it was probably too late to fix. And I am not aware of any vendor that implements the VENDOR_CFG capability.

But we can do better now by not introducing any new vendor specific stuffs.



I don't ask for workarounds. I want to create a clean spec definition for vendor to debug/control their special souse.


That's fine, but if it can't be generalized, it's better to be done at the layer under virtio.

what layer are you talking about ?

There is the virtio layer and the transport layer. That's it.

The transport layer has a small window for configuration and handshake.


Nope. The spec only cares about virtio related features. It doesn't prevent you from adding vendor specific features in the transport layer.


The virtio layer has ability to transfer data to/from driver from/to device.




For 2), virtio keeps simple as is, functionality is provided in a vendor specific device interface. In this case, you can't use virtio-pci directly, then you need present virtio on the upper layer (with some software meditation)

you mean VDPA ?


vDPA is one approach but not all.

Another example is the IFCVF, it has a dedicated bar for live migration which is not a part of the virtio-pci capability. (I'm not saying it's a good design, but it's indeed another approach).

Sorry, I don't this virtio spec should care about vDPA and IFCVF. This should be the other way around.

And you try to enforce the opposite.


No. It's not related to vDPA but just an example of adding vendor specific features.

If you look at the IFCVF driver codes, it's easy to see that the device could be probed by the standard virtio-pci driver.









This is the way to do it.


Again, for debug or acceleration, if you want to do it at the virtio level, you need generalize those features and define them in the spec.

Maybe we can start the work on generalizing the debug facility first. (adding Laurent who is working on this).

Virtio debug stuff can be generalized.

Vendor debug stuff should use vendor specific commands. A HW device has more than virtio state. It might have FW that controls it. It might be an SoC with a lot of components that are used to accelerate this device.


If the states/statistics/counters are highly vendor specific, let's do that under virtio(pci). Such method has been used by other vendors.

No other layers.


Virtio can't work by itself.



Lets stop mentioning this.


Let's keep the discussion constructive. I'm not obliged to design hardware for you, but obliged to figure out the design that violates the goal of the virtio spec. What I mentioned has been used by other vendor and it works well without bothering the virtio spec at all.

I think I've stated many times that adding vendor specific features in the spec is wrong, we want to have general features within a standard device. And you don't even explain why it must be done at virtio spec, (actually, not even defined in the spec but just leave a door for vendor to implement anything). Technically, you can have non virtio PF with virtio VF.






It's not always a QEMU code that implements virtio device.


It's unrelated to whether or not it's a software device. It's about the effort of the spec to present a standard device.

What I don't understand is that, the mlx5-vdpa approach has been proved to succeed in all points you raised above (I meant the vendor specific part). Why need to bother them in the virtio layer if the feature can't be generalized?

vDPA code shouldn't change at all.

Let's keep vDPA out of this discussion.

I can invent another my_virtio_data_path_acceleration and when I'll do that I don't expect the TC to change the spec to fit it.


I think we need some clarification on the concept "vDPA". To me it means virtio + vendor specific features (out of the spec).

Thanks




Thanks




Tahnks




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]