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

[Parav Pandit <parav@nvidia.com>]

> From: Halil Pasic <pasic@linux.ibm.com>
> Sent: Thursday, January 26, 2023 6:49 AM
> 
> On Wed, 25 Jan 2023 19:09:28 +0000
> Parav Pandit <parav@nvidia.com> wrote:
> 
> > > Would just
> > > "When VIRTIO_NET_F_CTRL_VLAN is not negotiated, no VLAN filtering is
> > > done by the device."
> > > work?
> > >
> > This is also fine.
> > However, I prefer the current spec terminology used in mac, promiscuous etc
> area such as "receive/accept/drop".
> > It is lot clearer to understand in steering world.
> > And it also aligns to the steering tools such as tc [3] which defines the action
> as "drop/mirred/redirect" etc.
> 
> My problem is not the word accept itself. Let me try to explain it once again,
> now that we have gotten rid of the confusing "as per device configuration".
> Now our sentence looks like this.
> 
> When VIRTIO_NET_F_CTRL_VLAN is not negotiated, the device MUST accept all
> VLAN tagged packets.
> 
> Let us analyze it.
> Predicate: "MUST accept"
> Object: "all VLAN tagged packets"
> Subject: "the device"
> 
> Compare that to man 8 tc. There they make it clear that there may the things
> like the next filter, and that those are comprised of actions.
> 
> I think, in a system with multiple filters, it is a very different piece of cake stating
> that a:
> * A certain filter accepts an input.
> * The whole system accepts an input.
> 
> If in our sentence the subject where not the "the device" but something like
> "the VLAN filtering facility" or you name it, I would be fine with that.
> 
> But when without the corresponding domain knowledge, the device MUST
> accept sounds like the driver of an conforming device will see that packet. I.e.
> the device dropping that very same packet for a different reason is not possible
> without violating that normative.
> 
> Of course with enough domain knowledge, one would know that we didn't
> really mean that the "the packet must be accepted by the device" but rather
> that the "VLAN filtering mechanism is not allowed to drop the give packet".
> Because the former makes no sense.
> 
> In the end, I believe the target audience of this document does have the
> domain knowledge to deal with the situation. But I prefer normative statement
> that don't lend themselves to misinterpretation.
> 
Yes. exactly. I did clarify in one of the previous response s(don't have the link handy) that steering section overall for mac, promiscuous, vlan etc flitering needs some rewrite for cross dependencies.
I would possibly drive it in a separate issue word it. Because the scope of it beyond just this issue.