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: <20201127010811.GR2075216@lunn.ch>
Date:   Fri, 27 Nov 2020 02:08:11 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Lukasz Majewski <lukma@...x.de>
Cc:     Vladimir Oltean <olteanv@...il.com>,
        Fugang Duan <fugang.duan@....com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Fabio Estevam <festevam@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Florian Fainelli <f.fainelli@...il.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Peng Fan <peng.fan@....com>, stefan.agner@...adex.com,
        krzk@...nel.org, Shawn Guo <shawnguo@...nel.org>
Subject: Re: [RFC 0/4] net: l2switch: Provide support for L2 switch on i.MX28
 SoC

> > I would push back and say that the switch offers bridge acceleration
> > for the FEC. 
> 
> Am I correct, that the "bridge acceleration" means in-hardware support
> for L2 packet bridging? 

You should think of the hardware as an accelerator, not a switch. The
hardware is there to accelerate what linux can already do. You setup a
software bridge in linux, and then offload L2 switching to the
accelerator. You setup vlans in linux, and then offload the filtering
of them to the accelerator. If there is something linux can do, but
the hardware cannot accelerate, you leave linux to do it in software.

> Do you propose to catch some kind of notification when user calls:
> 
> ip link add name br0 type bridge; ip link set br0 up;
> ip link set lan1 up; ip link set lan2 up;
> ip link set lan1 master br0; ip link set lan2 master br0;
> bridge link
> 
> And then configure the FEC driver to use this L2 switch driver?

That is what switchdev does. There are various hooks in the network
stack which call into switchdev to ask it to offload operations to the
accelerator.

> The differences from "normal" DSA switches:
> 
> 1. It uses mapped memory (for its register space) for
> configuration/statistics gathering (instead of e.g. SPI, I2C)

That does not matter. And there are memory mapped DSA switches. The
DSA framework puts no restrictions on how the control plane works.

> (Of course the "Section 32.5.8.2" is not available)

It is in the Vybrid datasheet :-)

   Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ