netdev - Re: [PATCH net-next v2 2/3] dsa: mv88e6xxx: Add support for RMU in select switches

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20220831152456.4ph25o75etwd5ayy@skbuf>
Date:   Wed, 31 Aug 2022 18:24:56 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Mattias Forsblad <mattias.forsblad@...il.com>
Cc:     netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net-next v2 2/3] dsa: mv88e6xxx: Add support for RMU in
 select switches

On Wed, Aug 31, 2022 at 08:12:09AM +0200, Mattias Forsblad wrote:
> Please elaborate why this may pose a problem, I might have missed
> some information.

Because as I said, you need to enable it over the CPU port connected to
the master which goes up and is operational, and you don't have this
information at probe time.

> > If you decide to rework this using the master netdev, you can use
> > dsa_tag_protocol_overhead(master->dsa_ptr->tag_ops). Or even reserve
> > enough headroom for the larger header (EDSA) and be done with it.
> > But then you need to construct a different header depending on whether
> > DSA or EDSA is used.
> > 
> 
> So in the new version a la qca8k we need the 'extra' parameter to
> see if we need space for EDSA header, thus we need run through the tagger.
> We can discuss that in the next version.

"thus we need run through the tagger" -> is this a justification that
you're going to keep the tag_ops->inband_xmit?

You don't _have_ to, you already have access to the tagging protocol in
use via chip->tag_protocol, you can derive from that if you need the E
in EDSA or not, and still keep everything within the switch driver.

> > Could you please explain for me what will setting skb->pkt_type to
> > PACKET_OUTGOING achieve?
> >
> 
> I though it was prudent, will remove if it's not needed.

I honestly don't know what it does.