OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

> From: Jason Wang <jasowang@redhat.com>
> 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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]