linux-kernel - Re: [PATCH net-next v8 3/5] net: dsa: add out-of-band tagging protocol

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20221115102924.1329b49f@pc-7.home>
Date:   Tue, 15 Nov 2022 10:29:24 +0100
From:   Maxime Chevallier <maxime.chevallier@...tlin.com>
To:     Felix Fietkau <nbd@....name>
Cc:     Jakub Kicinski <kuba@...nel.org>, davem@...emloft.net,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        thomas.petazzoni@...tlin.com, Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        linux-arm-kernel@...ts.infradead.org,
        Vladimir Oltean <vladimir.oltean@....com>,
        Luka Perkov <luka.perkov@...tura.hr>,
        Robert Marko <robert.marko@...tura.hr>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>
Subject: Re: [PATCH net-next v8 3/5] net: dsa: add out-of-band tagging
 protocol

Hello everyone,

Felix, thanks for the feedback !

On Tue, 8 Nov 2022 13:22:17 +0100
Felix Fietkau <nbd@....name> wrote:

[...]

> FYI, I'm currently working on hardware DSA untagging on the mediatek
> mtk_eth_soc driver. On this hardware, I definitely need to keep the
> custom DSA tag driver, as hardware untagging is not always available.
> For the receive side, I came up with this patch (still untested) for
> using METADATA_HW_PORT_MUX.
> It has the advantage of being able to skip the tag protocol rcv ops
> call for offload-enabled packets.
> 
> Maybe for the transmit side we could have some kind of netdev feature
> or capability that indicates offload support and allows skipping the
> tag xmit function as well.
> In that case, ipqess could simply use a no-op tag driver.

If I'm not mistaken, Florian also proposed a while ago an offload
mechanism for taggin/untagging :

https://lore.kernel.org/lkml/1438322920.20182.144.camel@edumazet-glaptop2.roam.corp.google.com/T/

It uses some of the points you're mentionning, such as the netdev
feature :)

All in all, I'm still a bit confused about the next steps. If I can
summarize a bit, we have a lot of approaches, all with advantages and
inconvenients, I'll try to summarize the state :

 - We could simply use the skb extensions as-is, rename the tagger
   something like "DSA_TAG_IPQDMA" and consider this a way to perform
   tagging on this specific class of hardware, without trying too hard
   to make it generic.

 - We could try to move forward with this mechanism of offloading
   tagging and untagging from the MAC driver, this would address
   Florian's first try at this, Felix's use-case and would fit well the
   IPQESS case

 - There's the option discussed by Vlad and Jakub to add several
   frontends, one being a switchev driver, here I'm a bit lost TBH, if
   we go this way I could definitely use a few pointers from Vlad :)

When looking at it from this point of view, option 2 looks pretty
promising, but I would like to make sure we're on the same page at that
point. On my side, I've tried several approaches for this tagging and
so far none are acceptable, for good reasons. I would like to make sure
then that I grasp the full picture and I didn't miss other possible
ways of addressing this.

Thanks everyone for your help !

Maxime