[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [virtio-comment] [PATCH v10] virtio-net: Clarify VLAN filter table configuration
> 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]