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

Parav Pandit
2023-08-08T04:11:16Z

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