On Tue, 8 Aug 2023 04:11:03 +0000, Parav Pandit <> wrote:
>
>
> > From: Xuan Zhuo <>
> > Sent: Tuesday, August 8, 2023 9:31 AM
> >
> > On Tue, 8 Aug 2023 03:16:44 +0000, Parav Pandit <> wrote:
> > >
> > >
> > > > From: Jason Wang <>
> > > > 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?
NO.
I mean the virtio-net device.
>
> > Now, you think we should introduce the rx/tx filter to the virtio switch.
> >
> I am asking to _not_ introduce currently.
I don't care whether swtich is introduced or not. Because we have no
dependencies on it.
My requirement is to implement ip restriction which is very important for cloud
scenarios.
I think the gap is, I don't care how it's implemented. Because for me, it can be
supported by switch rx, tx filter or virtio-net device. I'd love to hear
everyone's opinions.
Thanks.
