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: [virtio-comment] [PATCH v10] virtio-net: Clarify VLAN filter table configuration


On Wed, Jan 25, 2023 at 11:46:58PM +0000, Parav Pandit wrote:
> > > but vlans are different aren't they? Anyway changing that will need a
> > > new feature bit.
> > I do not the history for about "Note" on why it was made best effort.
> > To best of my knowledge, it should not be best effort.
> > Device should not overflow the table. It should fail the ADD call.

For the MAC table?  Failing commands generally is
a bad way to communicate to drivers. If we do there needs to also
be a way to report our limits. In this case it's enough to
look at qemu to see an implementation that just sets a "table
overflow" flag and stops filtering.

Similarly a populat vhost+bridge+tap combo does not keep
the copy of the mac table at all and instead realies on
guest sending announcement packets and bridge learning from these.


> > If the above claim of "Note" is not strong enough, we can probably run a
> > different issue to make it "MUST".
> > I am not sure we really need feature bit it we fix the note.
> 
> I clicked too early while typing.
> Since DEL operation doesn't synchronize with the data path of device and driver, at some point a packet in pipe can be still received with removed VLAN.
> So may be the note was added.
> But for sure ADD should not be best effort basis.

So for VLANs this was added by Tiwei. I guess it looked sane then
but now I don't remember the motivation. Tiwei CC'd.

-- 
MST



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