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=-6.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, 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 21A5AC43381 for ; Wed, 20 Feb 2019 17:24:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EA00121848 for ; Wed, 20 Feb 2019 17:23:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="RthELTLF" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726438AbfBTRX6 (ORCPT ); Wed, 20 Feb 2019 12:23:58 -0500 Received: from mail-qt1-f195.google.com ([209.85.160.195]:33275 "EHLO mail-qt1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725801AbfBTRX6 (ORCPT ); Wed, 20 Feb 2019 12:23:58 -0500 Received: by mail-qt1-f195.google.com with SMTP id z39so28146761qtz.0 for ; Wed, 20 Feb 2019 09:23:57 -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=CV/DLT4sCum1KJR6MwaJHS4wqCTAiDD3oUUuVGteRiA=; b=RthELTLFmu8qjPcgZltzCGEUo3pcHkuDUGg32lLzDgjpb61Im7vD4QnG8tnEAPWTMd UjlsioNWNeCxgu8y62IcTTYEmvjQF+mTknph94rnXfJOP02gA3JxQ/K78rtfrZdanRNU 82+3vuFgTgoIRsiVIceA5mfI+sIp2hlG4DtRM4wrJOK3HBYU6ZmjkTltMiiVZOOIz7BE kCTsxrw04XeLXdhaSi3YKUd0jpb7ZWoq5lwnKmfObO17LLmwK+GFJFfNEsFg5daa1eJw 5wzKWueVQe5wGcUhlGIJqLoEtzUorLXc0peVX8S8eHPqStp4I0zajnZqD6awoYAnkF7z OPhw== 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=CV/DLT4sCum1KJR6MwaJHS4wqCTAiDD3oUUuVGteRiA=; b=toODKUDqXZXMSsn4YvzFau34OiSWJrxclURC4ovd7FEw3BsokeVQiGPlqrP7nGOhKv uNUzQxGDs+XTUGeGBggAkc9nP42jFcD92zuzhl2AYJJVKUuM58KxJR+lrPdn3qRCCEQz oBmOgcoZxCBoGGpTvoyMp4Nt6LMhX63LniHBiCP2MkooetbK2REqicfA/V3OzC+8iOgh N9mkJZVgCJSGdUpgOZfMvVfNJMV+yEyXDruhPbghH8nvoSHaoziJqZLm82PM9EP2YjM4 641Ll8XqaIZMgQlU7bhEOQwwZdXz1F2hlUOKNofkza15cLiNwwc00/CqrIHHKzdRi1Tx dZGg== X-Gm-Message-State: AHQUAuZfcxeVJTXXvuFzIUXMW3f1izs0loRniqdpsptO3v6hrNsDmvIu plCh06mCI1r2RmEY5dfpJz8= X-Google-Smtp-Source: AHgI3IanEObWEw4pNaf/Yh1mNcvZMX1OqlST7o9mf7BXBeGN/hfqB0h8Odjbw1nW+sgVp/xBt6fWlQ== X-Received: by 2002:aed:23e1:: with SMTP id k30mr28387243qtc.17.1550683436966; Wed, 20 Feb 2019 09:23:56 -0800 (PST) Received: from localhost (modemcable249.105-163-184.mc.videotron.ca. [184.163.105.249]) by smtp.gmail.com with ESMTPSA id o135sm10924259qka.47.2019.02.20.09.23.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 20 Feb 2019 09:23:56 -0800 (PST) Date: Wed, 20 Feb 2019 12:23:55 -0500 Message-ID: <20190220122355.GB32192@t480s.localdomain> From: Vivien Didelot To: Russell King Cc: Andrew Lunn , Florian Fainelli , Heiner Kallweit , "David S. Miller" , netdev@vger.kernel.org Subject: Re: [PATCH net-next v3 3/3] net: dsa: enable flooding for bridge ports In-Reply-To: References: <20190220123615.fcyrlhz5jpx5ecgv@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 Wed, 20 Feb 2019 12:36:59 +0000, Russell King wrote: > Switches work by learning the MAC address for each attached station by > monitoring traffic from each station. When a station sends a packet, > the switch records which port the MAC address is connected to. > > With IPv4 networking, before communication commences with a neighbour, > an ARP packet is broadcasted to all stations asking for the MAC address > corresponding with the IPv4. The desired station responds with an ARP > reply, and the ARP reply causes the switch to learn which port the > station is connected to. > > With IPv6 networking, the situation is rather different. Rather than > broadcasting ARP packets, a "neighbour solicitation" is multicasted > rather than broadcasted. This multicast needs to reach the intended > station in order for the neighbour to be discovered. > > Once a neighbour has been discovered, and entered into the sending > stations neighbour cache, communication can restart at a point later > without sending a new neighbour solicitation, even if the entry in > the neighbour cache is marked as stale. This can be after the MAC > address has expired from the forwarding cache of the DSA switch - > when that occurs, there is a long pause in communication. > > Our DSA implementation for mv88e6xxx switches disables flooding of > multicast and unicast frames for bridged ports. As per the above > description, this is fine for IPv4 networking, since the broadcasted > ARP queries will be sent to and received by all stations on the same > network. However, this breaks IPv6 very badly - blocking neighbour > solicitations and later causing connections to stall. > > The defaults that the Linux bridge code expect from bridges are for > unknown unicast and unknown multicast frames to be flooded to all ports > on the bridge, which is at odds to the defaults adopted by our DSA > implementation for mv88e6xxx switches. > > This commit enables by default flooding of both unknown unicast and > unknown multicast frames whenever a port is added to a bridge, and > disables the flooding when a port leaves the bridge. This means that > mv88e6xxx DSA switches now behave as per the bridge(8) man page, and > IPv6 works flawlessly through such a switch. > > Signed-off-by: Russell King > --- > net/dsa/port.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/net/dsa/port.c b/net/dsa/port.c > index b84d010fb165..9e7aab13957e 100644 > --- a/net/dsa/port.c > +++ b/net/dsa/port.c > @@ -105,6 +105,11 @@ int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br) > }; > int err; > > + /* Set the flooding mode before joining */ Note that as stated by the comment just below, the port has already joined the bridge here. > + err = dsa_port_bridge_flags(dp, BR_FLOOD | BR_MCAST_FLOOD, NULL); > + if (err) > + return err; > + > /* Here the port is already bridged. Reflect the current configuration > * so that drivers can program their chips accordingly. > */ > @@ -113,8 +118,10 @@ int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br) > err = dsa_port_notify(dp, DSA_NOTIFIER_BRIDGE_JOIN, &info); > > /* The bridging is rolled back on error */ > - if (err) > + if (err) { > + dsa_port_bridge_flags(dp, 0, NULL); > dp->bridge_dev = NULL; > + } > > return err; > } > @@ -137,6 +144,9 @@ void dsa_port_bridge_leave(struct dsa_port *dp, struct net_device *br) > if (err) > pr_err("DSA: failed to notify DSA_NOTIFIER_BRIDGE_LEAVE\n"); > > + /* Port is leaving the bridge, disable flooding */ > + dsa_port_bridge_flags(dp, BR_LEARNING, NULL); > + > /* Port left the bridge, put in BR_STATE_DISABLED by the bridge layer, > * so allow it to be in BR_STATE_FORWARDING to be kept functional > */ This makes it clear that we must add this logic which sets the expected default flags into the bridge code itself. But this can be done later. Reviewed-by: Vivien Didelot