Messages in this thread | | | Subject | Re: [PATCH v2 net 1/2] net: dsa: sja1105: always enable the INCL_SRCPT option | From | Paolo Abeni <> | Date | Thu, 29 Jun 2023 11:36:38 +0200 |
| |
On Tue, 2023-06-27 at 12:42 +0300, Vladimir Oltean wrote: > Link-local traffic on bridged SJA1105 ports is sometimes tagged by the > hardware with source port information (when the port is under a VLAN > aware bridge). > > The tag_8021q source port identification has become more loose > ("imprecise") and will report a plausible rather than exact bridge port, > when under a bridge (be it VLAN-aware or VLAN-unaware). But link-local > traffic always needs to know the precise source port. > > Modify the driver logic (and therefore: the tagging protocol itself) to > always include the source port information with link-local packets, > regardless of whether the port is standalone, under a VLAN-aware or > VLAN-unaware bridge. This makes it possible for the tagging driver to > give priority to that information over the tag_8021q VLAN header. > > The big drawback with INCL_SRCPT is that it makes it impossible to > distinguish between an original MAC DA of 01:80:C2:XX:YY:ZZ and > 01:80:C2:AA:BB:ZZ, because the tagger just patches MAC DA bytes 3 and 4 > with zeroes. Only if PTP RX timestamping is enabled, the switch will > generate a META follow-up frame containing the RX timestamp and the > original bytes 3 and 4 of the MAC DA. Those will be used to patch up the > original packet. Nonetheless, in the absence of PTP RX timestamping, we > have to live with this limitation, since it is more important to have > the more precise source port information for link-local traffic.
What if 2 different DSA are under the same linux bridge, so that the host has to forward in S/W the received frames? (and DA is incomplete)
It looks like that such frames will never reach the relevant destination?
Is such setup possible/relevant?
Thanks,
Paolo
| |