[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220519173436.z7g2sshz5ivqlpe7@skbuf>
Date: Thu, 19 May 2022 17:34:37 +0000
From: Vladimir Oltean <vladimir.oltean@....com>
To: Florian Fainelli <f.fainelli@...il.com>
CC: Maxime Chevallier <maxime.chevallier@...tlin.com>,
"davem@...emloft.net" <davem@...emloft.net>,
Rob Herring <robh+dt@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"thomas.petazzoni@...tlin.com" <thomas.petazzoni@...tlin.com>,
Andrew Lunn <andrew@...n.ch>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Luka Perkov <luka.perkov@...tura.hr>,
Robert Marko <robert.marko@...tura.hr>
Subject: Re: [PATCH net-next v2 2/5] net: dsa: add out-of-band tagging
protocol
On Thu, May 19, 2022 at 10:11:13AM -0700, Florian Fainelli wrote:
> unless we somehow manage to put it in the linear portion of
> the SKB to avoid using any control buffer or extension.
But how? Essentially the DSA master has to look at a packet and
determine whether it came from DSA based on something which non-DSA
code could not have done. In fact, I'm looking at the calls to
skb_reset_mac_{header,len} from net/core/skbuff.c, specifically at VLAN
and MPLS, and I believe (but haven't tested) that pushing such headers
would also alter skb->mac_len to some value != ETH_HLEN. So simply
having the DSA master check whether DSA was there by checking whether
skb->mac_len is ETH_HLEN + DSA tag len could easily confuse DSA with
some other protocol of same header size.
Powered by blists - more mailing lists