Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <f494387c8d55d9b1d5a3e88beedeeb448f2e6cc3.camel@redhat.com>
Subject: Re: [PATCH v2 net 1/2] net: dsa: sja1105: always enable the
 INCL_SRCPT option
From:   Paolo Abeni <pabeni@redhat.com>
To:     Vladimir Oltean <vladimir.oltean@nxp.com>, netdev@vger.kernel.org
Cc:     Andrew Lunn <andrew@lunn.ch>,
        Florian Fainelli <f.fainelli@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>, linux-kernel@vger.kernel.org
Date:   Thu, 29 Jun 2023 11:36:38 +0200
In-Reply-To: <20230627094207.3385231-2-vladimir.oltean@nxp.com>
References: <20230627094207.3385231-1-vladimir.oltean@nxp.com>
         <20230627094207.3385231-2-vladimir.oltean@nxp.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) 
MIME-Version: 1.0
Precedence: bulk

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).
>=20
> 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.
>=20
> 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.
>=20
> 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