RE: RE: RE: RE: RE: RE: [virtio-comment] RE: RE: RE: RE: [RFC] virtio-net: support access and control the member devices

[Parav Pandit <parav@nvidia.com>]

> From: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Sent: Tuesday, August 8, 2023 12:15 PM

> > At that point, there may be two functions, PF and switching PF, switching PF
> filters the traffic of the PF.
> >
> > Anyways, I am just not finding it useful enough at current point in time for us
> as far mature alternatives exist that users are comfortable with.
> > I would like to listen to Xuan if they really have use case for having switching
> PF as virtio object or not.
> 
> So the switching PF is that there is a switch under all devices?
> 
Right. Switching PF controls the ports of the PF and VFs.

> If we use the switch rx/tx filter for the ip restriction, the PF with switch is
> enough,  we do not need the ip restirction for the PF.
I understood that you for some reason do not need restrictions for the PF.
I do not know why you don't need it. :)
Most cloud setups that I came across so far, needs it, but ok...
The design for the switch object needs to cover the PF as well, even though it may not be done initially.
(hint: an abstraction of switch port to be done, instead of doing things directly on the group member id).

We are seeing use cases reducing of having switch located on the PF for its VFs.
So please reconsider.
I remember you mentioned in past in other thread, that mac etc is controlled from the infrastructure side.
So, I repeatedly ask if you _really_ need to have the switch object as part of the owner PF or not.
Which sort of contradicts with locating the administrative switch on the owner PF.

If it does, flow filters vq that is being worked with Heng, Satananda, David and others seems right direction to implement simple->complex switch object progressively.