Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp552578pxp; Wed, 9 Mar 2022 08:04:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJy5ei0Hu9cpj35Beu6RQ4877woxys5rfcV7dqkkpZF8LBC1uiglbY5qTbZT5tFJxp1kOZIK X-Received: by 2002:a63:1e52:0:b0:380:ae84:256e with SMTP id p18-20020a631e52000000b00380ae84256emr375428pgm.84.1646841867245; Wed, 09 Mar 2022 08:04:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646841867; cv=none; d=google.com; s=arc-20160816; b=NtoucCPNv9Y5fuYa9MkNNruFKMCrOlOXmNAJfIOLRGHbCtBeLz5HJaKnJ1xPg5BnP5 llqwjoUsakzWN/wGixkJWnEgqMF3Obw7sqfvEMrlmhD8sG2oYYWbSQm7G7XjWVoT9zf8 G3AnZfMvufXb0EBoZWyB6tBkdR0LF/0Zh3kORLgCANG5CykW9817GMaN4SyPYq+/pMFf hoNqZtaS6hi0AMGVpjmodSw35lJPVAdjnGOggF6l8HInUfAoR8ySB6wnDspbqWQ+mlyP OBUALFptJ2UNr9QHYuPaIAiLY6ZvzIdMI9wZjzouFiYPm65jcg5cTtb4Zu1/bWDwwzPI jQAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=hE+S/0AbaM2pPcNCMSw4Jzqj4RQmx4E5rMxUDwkwLVU=; b=FNyxxj5/WLNWsTmlf5aZucjhUIOBIn4+WL3Wv8ZDyoOJAYuOadSUNf5JJIgFLfsvTG a0SSAcP8Jr3V38bLjufYaglj3CxubjqrbMiCptN3ARkefw0vmAE1tp3zAL26NeDvZbS3 pLwwNDwuzlrW6nV9o2LQGtxE4/6wJASTEwnuBZSuDImfjTALbd2GVnyz8kYSQIrNTbyJ qGnWr29yV7KJz5ywi8Me/SnOS3qtkL6S6XtRPev9dWFsz4qXFV+b7S6XeGS88G4be8/h OT6EcK5FqJYhTtTPZqc0FnRC+cOfc7AR1Tgdt42Z4juNF5H/OT+2BzJa6fCk+sqK+TGf G2Tw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@waldekranz-com.20210112.gappssmtp.com header.s=20210112 header.b=laFC8gg+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z10-20020a170903018a00b00151bcc06439si2365810plg.347.2022.03.09.08.04.06; Wed, 09 Mar 2022 08:04:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@waldekranz-com.20210112.gappssmtp.com header.s=20210112 header.b=laFC8gg+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233996AbiCIPsK (ORCPT + 99 others); Wed, 9 Mar 2022 10:48:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51568 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234001AbiCIPsH (ORCPT ); Wed, 9 Mar 2022 10:48:07 -0500 Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 55F9517EDA8 for ; Wed, 9 Mar 2022 07:47:07 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id 17so1619019lji.1 for ; Wed, 09 Mar 2022 07:47:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=waldekranz-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=hE+S/0AbaM2pPcNCMSw4Jzqj4RQmx4E5rMxUDwkwLVU=; b=laFC8gg+0MeWXFJEZV67/eLluhTcckbRqcldkSukV2V4XmAwYaFkLQjBdndAn5ZP0z mhC5v9D7OHl09L7LsjRRnYjfzlC2uZYBm8r2wLkackJwepfp1ji5jUdBgGFB7Xl1Iiim vDywbsAA1eY3CPdJe4gJYtx/9yVK2rSlwXTiM2lSaT+G+jyMMS9SRdR0APkgwzhYqOgi CxmkzfsC9VOSf90x7xvDq6sEC0EO6XkbIcdFlQhS1VFkYH1Nip4IAGGcuai3L78Ect2V eAxeu2xkRnfX7sJJUwoWU+N8mtHan/aHTMlgeCvECz6/4TZUHCC+Py1EEOx+/5csKhoU Fidg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=hE+S/0AbaM2pPcNCMSw4Jzqj4RQmx4E5rMxUDwkwLVU=; b=cn+y5RDPm371sbYpkaDj6KRXZaaotjI8DcR6Q2sev/FR5bUHv5onnyUsNAoLuPiOvJ Y7kxZWQF7TngHkZzWcn4SUPqzUH1CgdSdnXGEV4HcjmJ0fARxQIRQMKB3mUjHNjSVkxi FyTDyGfqAMzwKEMZVkAsXtv9KwhyV7NZHf6vXmtRi6rZt7GFiJWmq5rrxcTCOkGT8KQX NyXSYf76Cqmfm4UnJpOuuGhm49Ep+euMPNno5Dk7tfYhxiCxv157XL94doY3pZCo1Swf FSG6sR6zIn/H8PA+zrJZo7CJg5E7dpEpshU9relc22ASxrmsSzIlitmcmEuhMpvY6wQ0 ZiBg== X-Gm-Message-State: AOAM5309xQHGYLS6SkxjuDEqOnNoGzNrj4fZy0qGWMQilMakQgW8tDC7 S93YflFlZgMH5xPHJIhUunb4jQ== X-Received: by 2002:a2e:90ca:0:b0:246:48ce:ba0e with SMTP id o10-20020a2e90ca000000b0024648ceba0emr31858ljg.401.1646840823568; Wed, 09 Mar 2022 07:47:03 -0800 (PST) Received: from wkz-x280 (a124.broadband3.quicknet.se. [46.17.184.124]) by smtp.gmail.com with ESMTPSA id u12-20020a056512128c00b00446499f855dsm455715lfs.78.2022.03.09.07.47.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Mar 2022 07:47:03 -0800 (PST) From: Tobias Waldekranz To: Vladimir Oltean Cc: davem@davemloft.net, kuba@kernel.org, Andrew Lunn , Vivien Didelot , Florian Fainelli , Jiri Pirko , Ivan Vecera , Roopa Prabhu , Nikolay Aleksandrov , Russell King , Petr Machata , Cooper Lees , Ido Schimmel , Matt Johnston , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bridge@lists.linux-foundation.org Subject: Re: [PATCH v2 net-next 06/10] net: dsa: Pass VLAN MSTI migration notifications to driver In-Reply-To: <20220303222942.dkz7bfuagkv7hbpp@skbuf> References: <20220301100321.951175-1-tobias@waldekranz.com> <20220301100321.951175-7-tobias@waldekranz.com> <20220303222942.dkz7bfuagkv7hbpp@skbuf> Date: Wed, 09 Mar 2022 16:47:02 +0100 Message-ID: <87pmmvm8ll.fsf@waldekranz.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 04, 2022 at 00:29, Vladimir Oltean wrote: > On Tue, Mar 01, 2022 at 11:03:17AM +0100, Tobias Waldekranz wrote: >> Add the usual trampoline functionality from the generic DSA layer down >> to the drivers for VLAN MSTI migrations. >> >> Signed-off-by: Tobias Waldekranz >> --- >> include/net/dsa.h | 3 +++ >> net/dsa/dsa_priv.h | 1 + >> net/dsa/port.c | 10 ++++++++++ >> net/dsa/slave.c | 6 ++++++ >> 4 files changed, 20 insertions(+) >> >> diff --git a/include/net/dsa.h b/include/net/dsa.h >> index cfedcfb86350..cc8acb01bd9b 100644 >> --- a/include/net/dsa.h >> +++ b/include/net/dsa.h >> @@ -962,6 +962,9 @@ struct dsa_switch_ops { >> struct netlink_ext_ack *extack); >> int (*port_vlan_del)(struct dsa_switch *ds, int port, >> const struct switchdev_obj_port_vlan *vlan); >> + int (*vlan_msti_set)(struct dsa_switch *ds, >> + const struct switchdev_attr *attr); > > I would rather pass the struct switchdev_vlan_attr and the orig_dev > (bridge) as separate arguments here. Or even the struct dsa_bridge, for > consistency to the API changes for database isolation. Fair point. I'll change. >> + >> /* >> * Forwarding database >> */ >> diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h >> index 07c0ad52395a..87ec0697e92e 100644 >> --- a/net/dsa/dsa_priv.h >> +++ b/net/dsa/dsa_priv.h >> @@ -217,6 +217,7 @@ int dsa_port_vlan_filtering(struct dsa_port *dp, bool vlan_filtering, >> struct netlink_ext_ack *extack); >> bool dsa_port_skip_vlan_configuration(struct dsa_port *dp); >> int dsa_port_ageing_time(struct dsa_port *dp, clock_t ageing_clock); >> +int dsa_port_vlan_msti(struct dsa_port *dp, const struct switchdev_attr *attr); >> int dsa_port_mtu_change(struct dsa_port *dp, int new_mtu, >> bool targeted_match); >> int dsa_port_fdb_add(struct dsa_port *dp, const unsigned char *addr, >> diff --git a/net/dsa/port.c b/net/dsa/port.c >> index d9da425a17fb..5f45cb7d70ba 100644 >> --- a/net/dsa/port.c >> +++ b/net/dsa/port.c >> @@ -778,6 +778,16 @@ int dsa_port_bridge_flags(struct dsa_port *dp, >> return 0; >> } >> >> +int dsa_port_vlan_msti(struct dsa_port *dp, const struct switchdev_attr *attr) >> +{ >> + struct dsa_switch *ds = dp->ds; >> + >> + if (!ds->ops->vlan_msti_set) >> + return -EOPNOTSUPP; >> + >> + return ds->ops->vlan_msti_set(ds, attr); > > I guess this doesn't need to be a cross-chip notifier event for all > switches, because replication to all bridge ports is handled by > switchdev_handle_port_attr_set(). Ok. But isn't it called too many times > per switch? It is certainly called more times than necessary. But I'm not aware of any way to limit it. Just as with other bridge-global settings like ageing timeout, the bridge will just replicate the event to each port, not knowing whether some of them belong to the same underlying ASIC or not. We could leverage hwdoms in the bridge to figure that out, but then: - Drivers that do not implement forward offloading would miss out on this optimization. Unfortunate but not a big deal. - Since DSA presents multi-chip trees as a single switchdev, the DSA layer would have to replicate the event out to each device. Doable, but feels like a series of its own. >> +} >> + >> int dsa_port_mtu_change(struct dsa_port *dp, int new_mtu, >> bool targeted_match) >> { >> diff --git a/net/dsa/slave.c b/net/dsa/slave.c >> index 089616206b11..c6ffcd782b5a 100644 >> --- a/net/dsa/slave.c >> +++ b/net/dsa/slave.c >> @@ -314,6 +314,12 @@ static int dsa_slave_port_attr_set(struct net_device *dev, const void *ctx, >> >> ret = dsa_port_bridge_flags(dp, attr->u.brport_flags, extack); >> break; >> + case SWITCHDEV_ATTR_ID_VLAN_MSTI: >> + if (!dsa_port_offloads_bridge_dev(dp, attr->orig_dev)) >> + return -EOPNOTSUPP; >> + >> + ret = dsa_port_vlan_msti(dp, attr); >> + break; >> default: >> ret = -EOPNOTSUPP; >> break; >> -- >> 2.25.1 >>