RE: [virtio-dev] [PATCH v9] virtio-network: Clarify VLAN filter table configuration

[Parav Pandit <parav@nvidia.com>]

> From: Halil Pasic <pasic@linux.ibm.com>
> Sent: Monday, January 23, 2023 6:40 AM
> 
> On Wed, 11 Jan 2023 01:09:45 +0200
> Parav Pandit <parav@nvidia.com> wrote:
> 
> > The filtering behavior of the VLAN filter commands is not very clear
> > as discussed in thread [1].
> 
> >
> > Hence, add the command description and device requirements for it.
> >
> > [1]
> > https://lists.oasis-open.org/archives/virtio-dev/202301/msg00136.html
> 
> Sorry I could not find the discussion. Can you point me to the email where the
> discussion starts?
>
Latest patch is for this change is : https://lists.oasis-open.org/archives/virtio-dev/202301/msg00231.html

There was past discussion at https://www.mail-archive.com/qemu-devel@nongnu.org/msg913433.html

> > +\devicenormative{\subparagraph}{VLAN Filtering}{Device Types /
> > +Network Device / Device Operation / Control Virtqueue / VLAN
> > +Filtering}
> > +
> > +When VIRTIO_NET_F_CTRL_VLAN is not negotiated, the device MUST accept
> > +all VLAN tagged packets as per the device configuration.
> 
> I find "as per the device configuration" difficult to comprehend. Maybe we can
> work on this with an editorial. What are you trying to express here? On one
> hand you say "the device MUST accept all VLAN tagged packets" on the other
> hand "per the device configuration" may explain, or may relativize and restrict
> that statement.
> 
From VLAN filtering perspective, it should accept all packets, but this is subject to other device configuration such as MAC programming.
The current one is fine that cover both the aspects to VLAN specific and other config.

> Would
> "When VIRTIO_NET_F_CTRL_VLAN is not negotiated, VLAN filtering is not
> applied. I.e. VLAN tags are ignored by the device."
> also work?
>
No. its not about ignoring "VLAN tags". Its about dealing with "packets" that starts with the VLAN tag.
 
> > +
> > +When VIRTIO_NET_F_CTRL_VLAN is negotiated, the device MUST accept all
> > +VLAN tagged packets whose VLAN tag is present in the VLAN filter
> > +table and SHOULD drop all VLAN tagged packets whose VLAN tag is
> > +absent in the VLAN filter table.
> > +
> 
> Maybe it would be more fortunate to make these statements with respect to
> the VLAN filtering or VLAN filter, and not with respect to the device.
> 
> For example, if the package is otherwise broken or should be dropped for
> different reasons (maybe MAC filtering?).
> 
Here the context is only VLAN filter. Packet may be dropped for other reasons.
We preferably want to stay away from describing it such details here, because steering features are expected to grow.
And talking about each of them in cross section just complicates it. 

In near future, I plan to further improve and add a steering section, that will describe the hierarchy or interworking of these, unrelated to this.

> BTW why SHOULD drop?
This is the offload feature to drop such packets so that OS driver doesn't need to do the filtering work. :)