On 9/29/2022 12:13 AM, Michael S. Tsirkin wrote:
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.
Thanks, ticket filed at:
https://github.com/oasis-tcs/virtio-spec/issues/147
Also, is it ok if we make it a SHOULD, i.e. best effort filtering?
Yes, that's fine.
-Siwei
