On Wed, Sep 21, 2022 at 04:00:58PM -0700, Si-Wei Liu wrote: > > > > The spec doesn't explicitly say anything about that > > > > as far as I see. > > > Here the spec is totally ruled by the (software artifact of) > > > implementation rather than what a real device is expected to work with > > > VLAN rx filters. Are we sure we'd stick to this flawed device > > > implementation? The guest driver seems to be agnostic with this broken > > > spec behavior so far, and I am afraid it's an overkill to add another > > > feature bit or ctrl command to VLAN filter in clean way. > > > > > I agree with all of the above. So, double checking, all vlan should be > > allowed by default at device start? > That is true only when VIRTIO_NET_F_CTRL_VLAN is not negotiated. If the > guest already negotiated VIRTIO_NET_F_CTRL_VLAN before being migrated, > device should resume with all VLANs filtered/disallowed. > > > Maybe the spec needs to be more > > clear in that regard? > Yes, I think this is crucial. Otherwise we can't get consistent behavior, > either from software to vDPA, or cross various vDPA vendors.
OK. Can you open a github issue for the spec? We'll try to address. Also, is it ok if we make it a SHOULD, i.e. best effort filtering? -- MST