Re: RE: virtio-net ip restriction.

[Xuan Zhuo <xuanzhuo@linux.alibaba.com>]

On Mon, 14 Aug 2023 13:03:53 +0000, Parav Pandit <parav@nvidia.com> wrote:
>
> > 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?

On the cloud, the mac is not important, the DPU forwards the packets by the ip.
But you are right, we can introduce the support for mac.

>
> > ## 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.

For the switch part, I am ok.

But I would to know can we have two?



>
> >
> > 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.

YES.

But I think that the #2 is ok.

Your plan of the switching PF is the universal design to implement the ip
restriction.

But the ip restriction is the common requirement in virtio case.
We can support it in a virtio specific way.

>
>
> > > 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.

You said that the use cases for switching PF are dwindling. But you prefer to
implement ip restriction with switching PF. Am I right?

We know that the switch under all(PF, VF) is more complex.
So we all not plan to implement it.

Then how about we do not implement the switching PF for now.
We support ip restriction by the #2.

Then we can have an independent switch under all in the future.

>
> > > 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.

I do not got fully.

>
> > > 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?

In the past, we provided virtual machines. All virtual machines belong to
different tenants. DPU has ip restriction function by default(without virtio).
But more and more complex forms of services began to appear, they work on the
HOST. But they create virtual machines or Dockers to provide to their tenants.
For performance, each virtual machine or Docker uses a separate NIC provided by
the DPU. So they need to configure IP restrictions for these NICs.

So the form of the cloud is changing, more and more configurations are need by
the users from the host.


Thanks