should clarify VLAN tagging requirement with or without VIRTIO_NET_F_CTRL_VLAN

[siwliu-kernel]

The software virtio implementation in QEMU differentiates VLAN tagging
disposition subject to the presence of VIRTIO_NET_F_CTRL_VLAN feature:

• when VIRTIO_NET_F_CTRL_VLAN is negotiated, the device starts with
  all VLANs filtered (meaning only untagged traffic can be received,
  and traffic with VLAN tag will be dropped).
• when VIRTIO_NET_F_CTRL_VLAN is not negotiated, all traffic including
  untagged and tagged can be received.

It is essential to capture this expectation in the spec. Otherwise live migraiton
between different virtio implemenations won't work, either from software to
vDPA, or cross different vDPA vendors.

See the discussion thread in:
https://lists.oasis-open.org/archives/virtio-dev/202301/msg00231.html

[paravmellanox]

@mstsirkin ,

This is reviewed and ready for the vote.
https://lists.oasis-open.org/archives/virtio-dev/202301/msg00158.html

[mstsirkin]

BALLOT CREATED AT URL: https://www.oasis-open.org/committees/ballot.php?id=3750

ballot withdrawn, link to the proposed change was wrong.

[paravmellanox]

The software virtio implementation in QEMU differentiates VLAN tagging disposition subject to the presence of VIRTIO_NET_F_CTRL_VLAN feature:

* when VIRTIO_NET_F_CTRL_VLAN is negotiated, the device starts with
  all VLANs filtered (meaning only untagged traffic can be received,
  and traffic with VLAN tag will be dropped).

* when VIRTIO_NET_F_CTRL_VLAN is not negotiated, all traffic including
  untagged and tagged can be received.

It is essential to capture this expectation in the spec. Otherwise live migraiton between different virtio implemenations won't work, either from software to vDPA, or cross different vDPA vendors.

See the discussion thread in: https://www.mail-archive.com/qemu-devel@nongnu.org/msg912392.html

P.S. it would be nice to make sure the spec is not ruled by the software artifact (which was interpreted as "best effort" due to deficiency in previous software implementation) as in:

https://lists.oasis-open.org/archives/virtio-dev/201907/msg00035.html

The latest is https://lists.oasis-open.org/archives/virtio-dev/202301/msg00231.html.
The issue opener and fix are different hence this confusion.

[mstsirkin]

So I guess I will have to withdraw this ballot?

[siwliu-kernel]

Michael, would you be able to edit the ballot and correct the link to vote on as below:
https://lists.oasis-open.org/archives/virtio-dev/202301/msg00158.html

I think the link in issue description just pointed to the "best effort" wording that was once discussed in:
https://lists.oasis-open.org/archives/virtio-dev/201907/msg00035.html

[mstsirkin]

sorry, ballot description can not be changed after it started. as no one voted yet I have withdrawn the ballot.
please correct the github issue and request to =restart the ballot. Please follow the instructions here:
https://github.com/oasis-tcs/virtio-spec#use-of-github-issues

[siwliu-kernel]

Ok, updated the description with the link to the latest spec patch (v9) so @paravmellanox can restart the ballot.

Here captured the reference to the original disccusion thread in qemu-devel:

----------------------%<------------------------------%<----------------------
https://www.mail-archive.com/qemu-devel@nongnu.org/msg912392.html

P.S. it would be nice to make sure the spec is not ruled by the software
artifact (which was interpreted as "best effort" due to deficiency in previous
software implementation) as in:

https://lists.oasis-open.org/archives/virtio-dev/201907/msg00035.html
----------------------%<------------------------------%<----------------------

[siwliu-kernel]

Updated issue description with v10 patch to spec. @paravmellanox

[mstsirkin]

BALLOT CREATED AT URL: https://www.oasis-open.org/committees/ballot.php?id=3751