[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] Re: [virtio] [PATCH v10 04/10] admin: introduce virtio admin virtqueues
On 08/03/2023 14:08, Jiri Pirko wrote:
Wed, Mar 08, 2023 at 12:50:48PM CET, mst@redhat.com wrote:On Wed, Mar 08, 2023 at 11:05:00AM +0100, Jiri Pirko wrote: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.Yes. For example I find it likely that live migration/failover support will require a queue where driver pre-adds buffers and then device supplies information as state changes.I see. So there would be a queue called for example "child state virtqueue" or something like that for the sole purpose of getting the state of VF? Hmm, wouldn't it make more sense to have this done as a part of "group administrarion queue"? I mean, there is already notion of addresing child/VF here. So from my perspective, it is just another "group administration" command.
For sure VF Live Migration, MSIX config of VF, VF feature bits config and others should be admin commands on admin vq.
I don't see any reason introducing another type of admin-like vq.Also we don't need to have multiple admin vqs. This AQ is not aimed for performance.
We would have to prealloc buffers and use it for this purpose as well. I mean, the cmd payload for other group commands could be put in this buffers as well, making all group command infrastructure consistent. Something like: opcode X group_member_id 1 cmd_payload-> buffer A opcode Y group_member_id 1 cmd_payload-> buffer B Basically this would replace command_specific_data/command_specific_resultPassing 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?I used group administration virtqueue in a couple of places, just inconsistently. Good enough?Yep, sounds good. Thanks!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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]