[virtio-dev] Re: [virtio-comment] Re: [virtio] [PATCH v10 04/10] admin: introduce virtio admin virtqueues

[Jiri Pirko <jiri@nvidia.com>]

Tue, Mar 07, 2023 at 05:30:18PM CET, mst@redhat.com wrote:
>On Tue, Mar 07, 2023 at 08:36:41AM +0100, Jiri Pirko wrote:
>> Hmm, if not for now, the future exension would not be so simple, I fear.
>
>Without knowing what it is I can't say.

Yep, so basically you say, for other things if they appear,
let's introduce another queue type? If yes, sounds fair to me.


>
>> 
>> >
>> >Passing commands to devices themselves is already covered in spec
>> >reasonably well though not in a generic way.
>> 
>> You mean using the control queue, correct?
>
>Depends on the device type. network devices have a control queue, yes.
>
>> >From one of the patch description of this patchset I understand that you
>> cannot use control queue for this because control queue is
>> device-specific, yet group control is device-agnostic.
>> 
>> My undestanding therefore was, that the admin queue you are introducing
>> serves as a generic carrier for device-agnostic commands, in parallel
>> for having control queue serving as a generic carrier of device-specific
>> commands. If this is not the case, I think it would be nice to describe
>> the exact monivation and scope of admin queue.
>
>Nope unfortunately.  This queue is just a carrier for admin commands.
>admin commands are commands that talk to one device about other
>devices. There's clearly no mechanism in the spec to do that,
>so we plug this hole.

Okay, in that case "admin" sounds a bit misleading as for me it
implicates that this is for "administration" of the device. Yet is is
for the administration of other devices (slaves).

Perhaps there could be different term used to clarify?
Group leader virtqueue?
Group owner virtqueue?
Group master virtqueue?

>
>
>
>> 
>> >
>> >What we lack is passing commands about one device to another device.
>> >E.g. control VFs through PFs.
>> 
>> Could you provide examples of such commands please?
>
>For example a common feature is to program a vlan and have device
>put a given VF inside this vlan.

I don't follow entirely. The way how the VF is connected to network
should be ouf of the scope of this interface. The eswitch manager should
take care. What you say sounds awfully like the "ip vf" legacy
interface, which should not be considered here I believe.

If PF would be the eswitch manager, there are other means to do network
programming, using eswitch port representors. But I don't think this is
the can of worms we want to open now. I don't think we have a usecase
for it currently. Am I wrong Parav?



>
>In a virtualization scenario host controls this vlan programming giving
>the network a measure of protection from VFs.  If a VF is passed through
>to a VM, IOMMU limits VFs to only access guest memory so host has to do
>this programming through a PF.

Understood. This really looks like "ip vf" legacy. I strongly believe
it should not be supported.

Any other commands you have in mind?


>
>
>
>> 
>> >This is what groups do.
>> >But if we see more uses we can always add them.
>> >
>> >
>> >I'd rather avoid being too generic though.
>> 
>> In that case, why not to avoid using generic terms and stay
>> "group-centric"? What I mean is:
>> "Administration Virtqueues" -> "Group Administration Virtqueues"
>> "struct virtio_admin_cmd" -> "struct virtio_group_admin_cmd"
>> 
>> Etc. Helps to avoid confusion.
>
>Sure, I tried to do that but missed some opportunities.
>Will address.

Cool.


>
>> 
>> >
>> >
>> >
>> >
>> >> 
>> >> >+than one administration virtqueue.
>> 
>> 
>> [...]
>> 
>
>
>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/
>

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org