netdev - Crosschip bridge functionality

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-next>] [day] [month] [year] [list]

Message-ID: <Y6YDi0dtiKVezD8/@euler>
Date:   Fri, 23 Dec 2022 11:37:47 -0800
From:   Colin Foster <colin.foster@...advantage.com>
To:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        netdev@...r.kernel.org
Subject: Crosschip bridge functionality

Hello,

I've been looking into what it would take to add the Distributed aspect
to the Felix driver, and I have some general questions about the theory
of operation and if there are any limitations I don't foresee. It might
be a fair bit of work for me to get hardware to even test, so avoiding
dead ends early would be really nice!

Also it seems like all the existing Felix-like hardware is all
integrated into a SOC, so there's really no other potential users at
this time.

For a distributed setup, it looks like I'd just need to create
felix_crosschip_bridge_{join,leave} routines, and use the mv88e6xxx as a
template. These routines would create internal VLANs where, assuming
they use a tagging protocol that the switch can offload (your
documentation specifically mentions Marvell-tagged frames for this
reason, seemingly) everything should be fully offloaded to the switches.

What's the catch?

In the Marvell case, is there any gotcha where "under these scenarios,
the controlling CPU needs to process packets at line rate"?

Thanks for all the great documentation and guidance! (and patience)

Colin Foster