> From: Michael S. Tsirkin <[email protected]> > Sent: Thursday, January 26, 2023 11:31 AM > > On Thu, Jan 26, 2023 at 04:27:47PM +0000, Parav Pandit wrote: > > > > > > > From: Michael S. Tsirkin <[email protected]> > > > Sent: Thursday, January 26, 2023 12:08 AM > > > > > > 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. > > Failing the command when device cannot do the job is right way to tell the > driver to follow the contract in general terms. > > There's no contract though. My point is that table size is not in the spec. > As long > as that is the case failing because it's too big is a bad idea. > I agree that table size should be in the spec. But I am not convinced that a device should return a fake success and do something wonky behavior. For some legacy reason it may have been done, but spec guideline should not be to return some fake success..
> > > 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 I get undeliverable reply for Tiwei's email. I don't see vlan table being done on best effort in QEMU, nor in mlx5 vdpa device. Si-Wei, Do you know any implementation that attempts to do vlan on best effort? Otherwise we should clean this up. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
