From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C9CCDC64E7A for ; Fri, 27 Nov 2020 01:21:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8DFE5221FD for ; Fri, 27 Nov 2020 01:21:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392118AbgK0BIR (ORCPT ); Thu, 26 Nov 2020 20:08:17 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:52150 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388130AbgK0BIR (ORCPT ); Thu, 26 Nov 2020 20:08:17 -0500 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1kiSF9-0094AB-RR; Fri, 27 Nov 2020 02:08:11 +0100 Date: Fri, 27 Nov 2020 02:08:11 +0100 From: Andrew Lunn To: Lukasz Majewski Cc: Vladimir Oltean , Fugang Duan , "David S . Miller" , Jakub Kicinski , netdev@vger.kernel.org, Fabio Estevam , Vivien Didelot , NXP Linux Team , Florian Fainelli , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Peng Fan , stefan.agner@toradex.com, krzk@kernel.org, Shawn Guo Subject: Re: [RFC 0/4] net: l2switch: Provide support for L2 switch on i.MX28 SoC Message-ID: <20201127010811.GR2075216@lunn.ch> References: <20201125232459.378-1-lukma@denx.de> <20201126123027.ocsykutucnhpmqbt@skbuf> <20201127003549.3753d64a@jawa> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201127003549.3753d64a@jawa> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > 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