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

[Jason Wang <jasowang@redhat.com>]

On Tue, Aug 8, 2023 at 10:46âAM Xuan Zhuo <xuanzhuo@linux.alibaba.com> wrote:
>
> On Tue, 8 Aug 2023 10:18:15 +0800, Jason Wang <jasowang@redhat.com> wrote:
> > On Mon, Aug 7, 2023 at 2:13âPM Xuan Zhuo <xuanzhuo@linux.alibaba.com> wrote:
> > >
> > > On Fri, 4 Aug 2023 12:49:04 +0000, Parav Pandit <parav@nvidia.com> wrote:
> > > >
> > > >
> > > > > From: Michael S. Tsirkin <mst@redhat.com>
> > > > > Sent: Friday, August 4, 2023 4:03 PM
> > > >
> > > > > > >
> > > > > > > At this point to have port for owner device requires creating a dedicated
> > > > > switching object, to be located sometimes side by side inside the owner,
> > > > > sometimes outside.
> > > > > > > All of these cases to be crafted, please rethink if this is _really_ needed as
> > > > > virtio object or not.
> > > > > >
> > > >
> > > > > >
> > > > > > YES.
> > > > > >
> > > > > > We can hear others.
> > > > > >
> > > > > > @Jason @Michael
> > > > > >
> > > > > >
> > > > > > Thanks
> > > > >
> > > > >
> > > > > This is so abstract, hard to have any position as I'm not sure what we are
> > > > > discussing. If some virtio devices have an integrated switch then ability to
> > > > > control the switch through virtio seems useful.
> > > > >
> > > > True, for us, at this point we do not have plan to expose virtio switch device because users are not blocked on it.
> > >
> > >
> > > Also for us.
> > >
> > > But we need to limit the ip of every member device.
> >
> > This has been discussed somehow before we need probably more like:
> > spoof check and trust which are already supported by iproute2:
> >
> > https://lists.oasis-open.org/archives/virtio-comment/202101/msg00047.html
>
>
> Sorry, I do not think that the above patch is match for us.
>
> In our case, one VM user may use the IP of another VM user to send/receive
> packets.
>
> So if the above idea is useful to our case, cloud you explain more?
>
> >
> > > That is useful for cloud.
> > > Because the user of each VM is untrustworthy. We must limit the ip traffic of
> > > every member device.
> > >
> > > We have two choose:
> > >
> > > 1. add feature to device by cvq of pf(or admin queue?), that can limit the ip(receive and transmit).
> > > 2. add feature to switch, it can limit the ip for every port. If we choose this
> > >    way, I will try introduce the simple switch concept to the virtio-net.
> > >    Because except this we have not more requirement for the switch. So we donot
> > >    plan to introduce a complex switch.
> >
> > This requirement (IP limitation) sounds more like a filter feature
> > which seems not directly related to switch.
>
> Yes, this can be a filter feature. But we also need to limit the tx traffic.
>
> For receive traffic, many net cards support that the flowdirector(or RFF) can
> steer the traffic to the VF.
>
> https://dpdk.readthedocs.io/en/v17.11/howto/flow_bifurcation.html
>
> But for us, that is just work for the receive traffic,
> we also need to limit the tx traffic.
>
> So we want to introduce as the feature of the device.

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?

Thanks

>
> Thanks
>
>
>
> >
> > Thanks
> >
> > >
> > > Thanks.
> > >
> > >
> > > >
> > > > > Re:queues - it's not by chance that we have multiple admin queues.
> > > > > So driver can dedicate one queue to filtering commands if that's felt to be
> > > > > important.
> > > > >
> > > > Admin queue currently do not send non admin command of the device.
> > > > Would you propose admin queue for something else also for rtc or console or cryto device and indicate its role so device can understand what is coming to it.
> > >
> >
>