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;
From:   Vladimir Oltean <vladimir.oltean@nxp.com>
To:     Jakub Kicinski <kuba@kernel.org>
CC:     Maxime Chevallier <maxime.chevallier@bootlin.com>,
        "davem@davemloft.net" <davem@davemloft.net>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Eric Dumazet <edumazet@google.com>,
        Paolo Abeni <pabeni@redhat.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "thomas.petazzoni@bootlin.com" <thomas.petazzoni@bootlin.com>,
        Andrew Lunn <andrew@lunn.ch>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Russell King <linux@armlinux.org.uk>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        Luka Perkov <luka.perkov@sartura.hr>,
        Robert Marko <robert.marko@sartura.hr>,
        Andy Gross <agross@kernel.org>,
        Bjorn Andersson <andersson@kernel.org>,
        Konrad Dybcio <konrad.dybcio@somainline.org>
Subject: Re: [PATCH net-next v8 3/5] net: dsa: add out-of-band tagging
 protocol
Thread-Topic: [PATCH net-next v8 3/5] net: dsa: add out-of-band tagging
 protocol
Thread-Index: AQHY8HTAfetHoGxM5E6HcRPQNrr8s64vpgIAgAOw8wA=
Date:   Mon, 7 Nov 2022 11:27:37 +0000
Message-ID: <20221107112736.mbdfflh6z37sijwg@skbuf>
References: <20221104174151.439008-1-maxime.chevallier@bootlin.com>
 <20221104174151.439008-4-maxime.chevallier@bootlin.com>
 <20221104200530.3bbe18c6@kernel.org>
In-Reply-To: <20221104200530.3bbe18c6@kernel.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Zw8uqw0Y2RI3T5fYA7KYyF4BtS8ypcG/au66pPGGi3qb9dwjlpVC3slTJuIV?=
 =?us-ascii?Q?oUu4C9LNYetvy/PF8+mkn1mXEs7P1sQ1A+eRkgojLXpG96FQsn+d/NKd/Vvl?=
 =?us-ascii?Q?ulYilGLSmThzRuIM/gLQgn0vu5spVpbpQVVjppcM8wosJe7tb/K5YaHR6JdY?=
 =?us-ascii?Q?CEgLYP/bxvaaj7CSl5gsh/3JBZ5O0lgjGGLyDyUyjKe+VCfKtW2jfFpeEywI?=
 =?us-ascii?Q?FT2te7+HCOpMqB133SIHcQ/jEChuJVezQG9xvsPywxQOlyBIIW51mpkL0NOe?=
 =?us-ascii?Q?6MsWEyxFWDdpaq7SQgOtBjmtHdElrArlWipRVfyd+FgID19nwuKCRPO9SySq?=
 =?us-ascii?Q?hcBPSYRqUZ6ye+IwF/eu0qq8POniFKiYPeY/JSPl0JoTiVa3AOslwpLXpJ69?=
 =?us-ascii?Q?ghkX64E1XbhndyTfYYSmfsvPKJF/wFqGW/NmUvMkn9LpUdJL3/PJfr2SvzXB?=
 =?us-ascii?Q?EmxasBypqTaFFePzwTjpKGP65kjOp6mReFc0uiYpxRA6uVHlE18d2ivM+WiF?=
 =?us-ascii?Q?2uUMguvkCNJYk0zsGZuJB6Bb8D/W4c4oBu28y4NBtywUZ5vUbtO3ey8eyXjS?=
 =?us-ascii?Q?2RXJdWURR8ZG1YFHpkJo9rJmzrCZ3XAHsxg8nB8tYK6nBanPjR4uv5gHBhO1?=
 =?us-ascii?Q?W8oZmQRT2uM6IH9uIAssC0rn9RAyYdsyeCic10J7AfGuJKcUnkAegTK/6SE+?=
 =?us-ascii?Q?ailApkgktcHSZt84U+vNy9M/1PkvxGk/5aZY0Wv2nJltJnRu+/1tvus52Dk1?=
 =?us-ascii?Q?ZaihP9PbqN51z6NsD5z9UJrqBEjfm/Ms4PNzBsno7/U0oYSuyeYo2YMGtV7G?=
 =?us-ascii?Q?wpuwQ0HU+Gb88N0aZEm046JU+lkXRv7NEomaVKmMzryXqrdKxg9C2FPcnUW5?=
 =?us-ascii?Q?5ZID2+dJMOAceWL3Gdop8XMbgM374foFiCmA4pG40Fwfbefl3V7cigdzZxRv?=
 =?us-ascii?Q?Kkyw6O75y+O+ueTIJ36jY/MoPps3CT7ydRnEAli/TATya5MiE+NZhX4rVCYK?=
 =?us-ascii?Q?Z8g4YUXWbTKu5D7IM8pCzzbgaUletoeVDwNjkoVameUn/LuvoQ+Q7IMAuYFH?=
 =?us-ascii?Q?qi2fzsIRBtv+m2EyM+UkoIP8tPbsi92BQhkHMKeiRAxLqGoph67C+oFAWQk3?=
 =?us-ascii?Q?DpvtnYiQKWNBHI0l35bsnbLvNt63PLoH/Oql2jIdLkEUvJaH5tzoXl94uCN1?=
 =?us-ascii?Q?DqjcbPSQ32UBn/AthaxmMXX97hfSknbd/TEAnGVifxetnkEh2sk7qJotzzVp?=
 =?us-ascii?Q?bEPSrYSlZA2obL2jp+pRgRschJ1P9kuQUILwqx8lVK4KEGqlE/AY7caaA/LY?=
 =?us-ascii?Q?bTmgLayCDn3H55aRRvt32yA8kMaZz9K1Qa0GFLYHi2cxETS8PBK2i8q3ZMPD?=
 =?us-ascii?Q?5SzTn9n/eMcQalehWeMV+WSrpLxlNmKWmUoqT0szGuIs+TgtuFiwXzt0zQHh?=
 =?us-ascii?Q?9hcNkLIYZ9kSmUubfXHl4govccZ0YKeZgmJ8Gj7UkoVWlMxiayEt+HBbNXOA?=
 =?us-ascii?Q?EX4TYph6gnccIll2q6vumKhTZ7yD0wX9WXeu/liXkQUrKLK6X517ffG0HhM1?=
 =?us-ascii?Q?18vYFvMWmEx5aHObrQl+UmLBkBRYb4xsAb44c+MuyRqYrhJ3EjYUS5PNvHua?=
 =?us-ascii?Q?Fg=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DF655BDE7533F4438087FD5416E3243A@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d7d7759f-cf23-4e64-ae03-08dac0b312ba
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2022 11:27:37.2093
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: RIMC/2yovuY6iIB187GPsYmZJr+9Tw8cbnJ4q+osUqTJruC23a3DZePbKhSrp+dqCWi9G3dUdnbhY2TiQe5DIg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR04MB8270
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Jakub,

On Fri, Nov 04, 2022 at 08:05:30PM -0700, Jakub Kicinski wrote:
> On Fri,  4 Nov 2022 18:41:49 +0100 Maxime Chevallier wrote:
> > Add a new tagging protocol based on SKB extensions to convey the
> > information about the destination port to the MAC driver
>
> This is what METADATA_HW_PORT_MUX is for, you shouldn't have
> to allocate a piece of memory for every single packet.

Since this is the model that skb extensions propose and not something
that Maxime invented for this series, I presume that's not such a big
deal? What's more, couldn't this specific limitation of skb extensions
be addressed in a punctual way, via one-time calls to __skb_ext_alloc()
and fast path calls to __skb_ext_set()?

I'm unfamiliar to the concept of destination cache entries and even more
so to the concept of struct dst_entry * carrying metadata. I suppose the
latter were introduced for lack of space in struct sk_buff, to carry
metadata between layers that aren't L3/L4 (where normal dst_entry structs
are used)? What makes metadata dst's preferable to skb extensions?
The latter are more general; AFAIK they can be used between any layer
and any other layer, like for example between RX and TX in the
forwarding path. Side note, I am not exactly clear what are the lifetime
guarantees of a metadata dst entry, and if DSA's use would be 100% safe
(DSA is kind of L3, since it has an ETH_P_XDSA packet_type handler, not
an rx_handler).

More importantly, what happens if a DSA switch is used together with a
SRIOV-capable DSA master which already uses METADATA_HW_PORT_MUX for
PF-VF communication? (if I understood the commit message of 3fcece12bc1b
("net: store port/representator id in metadata_dst") correctly)=