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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
