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

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

On Tue, 8 Aug 2023 04:16:59 +0000, Parav Pandit <parav@nvidia.com> wrote:
>
> > From: Jason Wang <jasowang@redhat.com>
> > Sent: Tuesday, August 8, 2023 9:21 AM
>
> > > The idea is to introduce filters on the new virtio switch object for tx and rx
> > both.
> >
> > It can be done in this way for sure but the question is why it must be done in
> > this way.
> This option because it is in use by very big and mature eco system of multiple sw stacks, kernel subsystem, drivers, and nics for several years now.
>
> > A drawback of using switch is that it introduces dependencies.
> >
> Feature is not a dependency. :)
>
> > > A virtio switch object can be part of a existing virtio device or a new virtio
> > device type in itself.
> >
> > That's fine.
> >
> > >
> > > Xuan,
> > > As we discussed, since the owner device packets also needs to be
> > > filtered, potentially outside of the owner device itself,
> >
> > This seems the admin request out of the scope of virtio.
> >
> Not really, it could be virto switch device that manage PF also.
> 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?

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.

Thanks.


>
>
>