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 9:31 AM
> 
> On Tue, 8 Aug 2023 03:16:44 +0000, Parav Pandit <parav@nvidia.com> wrote:
> >
> >
> > > From: Jason Wang <jasowang@redhat.com>
> > > Sent: Tuesday, August 8, 2023 8:39 AM
> >
> > >
> > > Yes, but even for TX, would it be better to filter the IP as early
> > > as possible in the TX path other than depend on the switch to do that?
> >
> > The idea is to introduce filters on the new virtio switch object for tx and rx
> both.
> 
> Filters for tx?
>
Yes. the regular switchdev model that exists in Linux kernel for several years now.
And similar in another hypervisor.
 
> Are there other use cases?
> 

> 
> > A virtio switch object can be part of a existing virtio device or a new virtio
> device type in itself.
> >
> > Xuan,
> > As we discussed, since the owner device packets also needs to be
> > filtered, potentially outside of the owner device itself,
> >
> > Do you see the need to introduce virtio switch object now, or can it wait?
> 
> For virtio switch, I am ok.
> 
I didn't follow your answer "I am ok".
Do you see the need now or can it wait?

> But for me, I just have this requirement that needs the switch.

> So if we do this in the device, then that is not need for me.
> 
Device meaning outside of the virtio domain, for example dpu or something else, yes?

> Now, you think we should introduce the rx/tx filter to the virtio switch.
>
I am asking to _not_ introduce currently.