RE: [virtio-comment] [PATCH v10] virtio-net: Clarify VLAN filter table configuration

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> 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 <mst@redhat.com>
> > > 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.