[virtio-dev] Re: RE: RE: RE: RE: RE: [virtio-comment] RE: RE: RE: RE: [RFC] virtio-net: support access and control the member devices
On Tue, 8 Aug 2023 03:16:44 +, 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? 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. 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. Now, you think we should introduce the rx/tx filter to the virtio switch. @Jason @Michael how do you think? Thanks. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] RE: RE: RE: RE: RE: RE: [virtio-comment] RE: RE: RE: RE: [RFC] virtio-net: support access and control the member devices
> From: Xuan Zhuo > Sent: Tuesday, August 8, 2023 9:31 AM > > On Tue, 8 Aug 2023 03:16:44 +, 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? > Now, you think we should introduce the rx/tx filter to the virtio switch. > I am asking to _not_ introduce currently. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] RE: RE: RE: RE: RE: RE: [virtio-comment] RE: RE: RE: RE: [RFC] virtio-net: support access and control the member devices
> -Original Message- > From: virtio-dev@lists.oasis-open.org > On Behalf Of Parav Pandit > Sent: Monday, August 7, 2023 9:11 PM > To: Xuan Zhuo > Cc: virtio-dev@lists.oasis-open.org; virtio-comment@lists.oasis- > open.org; Michael S. Tsirkin ; Jason Wang > > Subject: [EXT] [virtio-dev] RE: RE: RE: RE: RE: RE: [virtio-comment] RE: > RE: RE: RE: [RFC] virtio-net: support access and control the member > devices > > External Email > > -- > > > > From: Xuan Zhuo > > Sent: Tuesday, August 8, 2023 9:31 AM > > > > On Tue, 8 Aug 2023 03:16:44 +, 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. This is what representors would be used for. The Tx of representee is the RX of representor. Hence one can install RX L4/L3/L2 filters of choice on representor using tc flower, offload to device if need be, these would then be applied on the tx path of representee. Similarly the owner device can also have rx filters installed to direct traffic to the the representee. > 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. > > - > To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org > For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: RE: RE: RE: RE: RE: [virtio-comment] RE: RE: RE: RE: [RFC] virtio-net: support access and control the member devices
On Tue, 8 Aug 2023 04:16:59 +, Parav Pandit wrote: > > > From: Jason Wang > > 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. > > > - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] RE: RE: RE: RE: RE: RE: [virtio-comment] RE: RE: RE: RE: [RFC] virtio-net: support access and control the member devices
> From: Xuan Zhuo > Sent: Tuesday, August 8, 2023 12:15 PM > > 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? > Right. Switching PF controls the ports of the PF and VFs. > 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. I understood that you for some reason do not need restrictions for the PF. I do not know why you don't need it. :) Most cloud setups that I came across so far, needs it, but ok... The design for the switch object needs to cover the PF as well, even though it may not be done initially. (hint: an abstraction of switch port to be done, instead of doing things directly on the group member id). We are seeing use cases reducing of having switch located on the PF for its VFs. So please reconsider. I remember you mentioned in past in other thread, that mac etc is controlled from the infrastructure side. So, I repeatedly ask if you _really_ need to have the switch object as part of the owner PF or not. Which sort of contradicts with locating the administrative switch on the owner PF. If it does, flow filters vq that is being worked with Heng, Satananda, David and others seems right direction to implement simple->complex switch object progressively. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
