RE: virtio-net ip restriction.

[Parav Pandit <parav@nvidia.com>]

> From: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Sent: Tuesday, August 8, 2023 1:35 PM
> 
> ## Background
> 
> For cloud, the ip restriction is important. Because the user of the vm is
> untrustworthy. One user may use the ip of another to config the netdevice to
> receive and send packets. So we need to restrict the ip traffic of the device(or
> port).
>
A VM can do the same with the mac address too.
Why is mac ignored?
 
> ## Implement
> Now we have these choice:
> 
> 1. introduce the switch(as the part of pf or as a separate device under all PF
>    and VFs ), the switch support rx/tx filter 2. the virtio-net device support the ip
> restriction
>
#1 is the right approach, it is not either or.
Virtio switch object can be part of the virtio-net device or it can be indepdent device in itself.
So the definition we do should be generic enough so that it can be done as part of indepdent device in future without replicating all.

The concept of switch port etc is needed.
 
> 
> Parav wrote:
> > 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...
> 
> PF is used by the administrator, so the ip restriction for the PF is not important.
> But we can have this feature.
>
In some cloud a PF is also owned by the tenant.
Hence its administration to be done outside of the PF.
Therefore the virtio switch object definition to be built for long term and apply to a narrow case for now as PF->VF.

 
> > 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 for you, we should introduce a switching PF?
>
Yes.
 
> > So please reconsider.
> > I remember you mentioned in past in other thread, that mac etc is controlled
> from the infrastructure side.
> 
> YES.
>
Hence the administrative PF doing switching and VF configuration is desired.
 
> > So, I repeatedly ask if you _really_ need to have the switch object as part of
> the owner PF or not.
> 
> For me, that are all ok.
> Could you explain the difference between these?
> So I would to know which one is better and which one is simper?
> 
> > Which sort of contradicts with locating the administrative switch on the
> owner PF.
> 
> Why?
> 
> For us, all is on the DPU.
>
If all is on the DPU, can the ip restriction be applied on the DPU for the VFs (where there may not be any virtio net device).
If so, why do we need to introduce things now?