> From: Jiri Pirko <j...@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. 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. 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. --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
