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

[Jiri Pirko <jiri@nvidia.com>]

Wed, Mar 08, 2023 at 10:45:18PM CET, parav@nvidia.com wrote:
>
>> From: Jiri Pirko <jiri@nvidia.com>
>> Sent: Wednesday, March 8, 2023 5:05 AM
>
>> >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?
>> 
>> 
>We want the ability to program/provision the virtio feature bits and virtio config space parameters of the VF through PF.
>These are host-facing parameters that usually migrate from one to another host when a VF migrates.

Here is where we lack to have separate "devlink function" entity,
independend of "devlink port" :/ I mean, for MAC config and irq vectors.
What other host facing parmeters you have in mind. VLAN of "ip vf" is
definitelly one of them, I have to emphasize.


>
>A future device may even do this out of band, but we are far from it.
>At that point in the future virtio management device can take birth and do things over it.
>
>ip vf was legacy interface and it is not applicable here.

Agreed, unacceptable to implement "ip vf" legacy interfaces in
virtio_net from my perspective.


>virtio net doesn't implement it either and I don't see any user asking for it either.
>All users have migrated to using tc mechanism for long time now.

Okay, so the bottom line is, we should take care of host facing config
of VF, but we should not care about network plug of VF - that stays out
of the scope.