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=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 85FA7C43381 for ; Tue, 19 Feb 2019 17:00:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4DD292147A for ; Tue, 19 Feb 2019 17:00:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="qfuk6ANZ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727303AbfBSRAD (ORCPT ); Tue, 19 Feb 2019 12:00:03 -0500 Received: from mail-qt1-f195.google.com ([209.85.160.195]:43074 "EHLO mail-qt1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726321AbfBSRAD (ORCPT ); Tue, 19 Feb 2019 12:00:03 -0500 Received: by mail-qt1-f195.google.com with SMTP id y4so23889126qtc.10 for ; Tue, 19 Feb 2019 09:00:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:message-id:from:to:cc:subject:in-reply-to:references :mime-version:content-disposition:content-transfer-encoding; bh=lRIeDtD8hMzu6DqAIdoU1iQp0cCZ0fOtWApUrygIKBw=; b=qfuk6ANZV3X20R6VxaeQnczRM4kDx4uUZyd+c/ZJnsZvvmbJdLduwyBHfIcXk6Ys1+ zblJl4hIbWiiIqv8PyqRd6rthxK4zloXq3BjZNMYxKnPh0qG9FlTVqbFjBG2GEduR8zM Os1BlStZ/nOjl6VzXWHKi0kBmGt3xp5gHGRaV/wKAwDa5URYVyIBSP3h/vg7I92yfn1z Bjc1FN9v6iyFT+zPzWXmGwEBlmUbD9NBNbcC+47C4ZgzchKO46+FRjE5nogXWn0SlHL/ NdIFje1utm9sIt5wwBQ/Ptj55HpcDuSzKCqbGZ1047jtEhR/AIHyLM0nVZidfsQYWlgZ NHzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:from:to:cc:subject:in-reply-to :references:mime-version:content-disposition :content-transfer-encoding; bh=lRIeDtD8hMzu6DqAIdoU1iQp0cCZ0fOtWApUrygIKBw=; b=pUFk7I0hZvCafzMTKK8LGrSRFm5XoKcUIoc2fGLaHQBjzsFsZKjGcAgwcwZyjhsF4F DCVxjKHFeI9i5icsy/0j+ZB6zrsDc8+5Nwg3JFN4iAhtQK5vzQmkf8szwLvl3xupQHjv nJY9nrAH6+evUVq1TJI7bsMpEZeZoJgpDFLdxKoXZ9LlFqHNqJMwiyCgRILiRqoWZxXL nLxbRf6MAehMgFQo18SbzcPb0/5qP0jgaTFbyOHjg2sqBm9eitiSxEGXI1E1PD34b4E2 d8S7D8TobqmGTX8/EE04Ml/5UW1fnDg67vtQ8iQw+DMByNOg6L+zKN4fh40iFiVDiK8A 6qkw== X-Gm-Message-State: AHQUAuYhFD8jSWq092wpd9E3bct5b0heBkLiivWt+aEfVCz5AO17dGVX cvOE4ZDffRFf1IBp97E7T9BjQoNU X-Google-Smtp-Source: AHgI3IZx4jwyYk1fBduA8sfYZbvpy2zt+HdY0uFB1Ps8Ba3GjwaX60SV0dybjHTWb2s/ZVCXEz0CzA== X-Received: by 2002:ac8:1102:: with SMTP id c2mr23532596qtj.195.1550595601874; Tue, 19 Feb 2019 09:00:01 -0800 (PST) Received: from localhost (modemcable249.105-163-184.mc.videotron.ca. [184.163.105.249]) by smtp.gmail.com with ESMTPSA id t26sm11142570qkl.73.2019.02.19.09.00.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 19 Feb 2019 09:00:01 -0800 (PST) Date: Tue, 19 Feb 2019 12:00:00 -0500 Message-ID: <20190219120000.GB4140@t480s.localdomain> From: Vivien Didelot To: Russell King - ARM Linux admin Cc: Andrew Lunn , Florian Fainelli , Heiner Kallweit , "David S. Miller" , netdev@vger.kernel.org Subject: Re: [PATCH net-next v2 2/3] net: dsa: mv88e6xxx: add support for bridge flags In-Reply-To: <20190219162435.f5zl5harbarwy6bj@shell.armlinux.org.uk> References: <20190217163114.yomawlljyxlqy3ob@shell.armlinux.org.uk> <20190219111612.GF27578@t480s.localdomain> <20190219162435.f5zl5harbarwy6bj@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi Russell, On Tue, 19 Feb 2019 16:24:35 +0000, Russell King - ARM Linux admin wrote: > > > +static unsigned long mv88e6xxx_bridge_flags_support(struct dsa_switch *ds) > > > +{ > > > + struct mv88e6xxx_chip *chip = ds->priv; > > > + unsigned long support = 0; > > > + > > > + if (chip->info->ops->port_set_egress_floods) > > > + support |= BR_FLOOD | BR_MCAST_FLOOD; > > > + > > > + return support; > > > +} > > > > I think that it isn't necessary to propagate the notion of bridge flags down > > to the DSA drivers. It might be just enough to add: > > > > port_egress_flood(dsa_switch *ds, int port, bool uc, bool mc) > > > > to dsa_switch_ops and set BR_FLOOD | BR_MCAST_FLOOD from the DSA core, > > if the targeted driver has ds->ops->port_set_egress_flood. What do you think? > > There are two other flags that I haven't covered which the bridge code > expects to be offloaded, and those are the broadcast flood flag and > the learning flag. I see. What does the bridge code do if these flags are set? Does it expect the underlying devices to handle ff:ff:ff:ff:ff:ff magically or does it program this entry into the bridged ports? In the latter case we have almost nothing to do. In the former case, we can make the core call dsa_port_mdb_add on setup and when a VLAN is added. mv88e6xxx tries to be smart and is already doing that and I'm really not a fan. If tomorrow there's a switch capable of simply toggling a bit to do that, we can add a new ops and skip the port_mdb_add call in the core. > I know that the Marvell switches don't have a bit to control the > broadcast flooding, that appears to be controlled via a static entry > in the ATU which would have to be modified as the broadcast flood flag > is manipulated. I don't know how that is handled in other bridges. > > Do we want to include the broadcast flood in the above prototype? > If we go for this, how do we detect which options a switch supports? If the necessary dsa_switch_ops routine is correctly prototyped, having it implemented by a driver or not should be enough to inform the core that the related feature(s) is/are supported by the switch. I'll try to give a bit more context on why I'd prefer this approach, hoping it makes sense: a switch driver does not need to understand bridge flags per-se, the core should give enough abstraction to this layer (and any other net-specifics). The core just needs to know if a driver can program this or that. More importantly, it can easily become messy to maintain switch-cases of arbitrary flags in all drivers and the core. Thanks, Vivien