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.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED 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 EE1E7C43381 for ; Sun, 17 Feb 2019 16:32:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BB51D2190C for ; Sun, 17 Feb 2019 16:32:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="Q5ul0m2r" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726995AbfBQQcs (ORCPT ); Sun, 17 Feb 2019 11:32:48 -0500 Received: from pandora.armlinux.org.uk ([78.32.30.218]:39742 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726087AbfBQQcs (ORCPT ); Sun, 17 Feb 2019 11:32:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Date:Sender:Message-Id:Content-Type: Content-Transfer-Encoding:MIME-Version:Subject:Cc:To:From:References: In-Reply-To:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9XeFF4SoJtOWInuQzcqRJL/pNl++IGCuDezhtrXQyMA=; b=Q5ul0m2rpJv4cuHdsXXU+iKIrd c1aINkjHfmuT7tRLpSUNF2VXVY6ovd7JnP/zDNR2qT0/K5JecH2GhGppsC2rxWXjoAsbi5uBYzUkY Ngk6V4fFlfMd/56GxB1XQ3LCNPe5mPzv8TR12DB2xH34k5irRjDvE8Jfs0OipkEg/7NkuROkVe69n YVc8L9nr7LWNDegNSjwQkgY5TPpIEn3XP4OKpcfZC6iOJRp5pnyCDUPAwfqqTZG2bERBkuv7epve6 VJus2HRwRlmxBdSRpQkmYhFCO6he7cewTLAVwDf+XTaoTsSyMf2Z8QG3l4Bsldu5GXP7MgIpt2PIj QquiU7ow==; Received: from e0022681537dd.dyn.armlinux.org.uk ([fd8f:7570:feb6:1:222:68ff:fe15:37dd]:47268 helo=rmk-PC.armlinux.org.uk) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gvPMw-0001JK-2o; Sun, 17 Feb 2019 16:32:42 +0000 Received: from rmk by rmk-PC.armlinux.org.uk with local (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1gvPMu-0000Ax-Ba; Sun, 17 Feb 2019 16:32:40 +0000 In-Reply-To: <20190217163114.yomawlljyxlqy3ob@shell.armlinux.org.uk> References: <20190217163114.yomawlljyxlqy3ob@shell.armlinux.org.uk> From: Russell King To: Andrew Lunn , Florian Fainelli , Vivien Didelot Cc: Heiner Kallweit , "David S. Miller" , netdev@vger.kernel.org Subject: [PATCH net-next v2 3/3] net: dsa: mv88e6xxx: default to multicast and unicast flooding MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" Message-Id: Date: Sun, 17 Feb 2019 16:32:40 +0000 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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 has defaulted to having multicast and unicast flooding disabled. 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 that unknown unicast frames and unknown multicast frames are flooded to all stations, 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. 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 --- drivers/net/dsa/mv88e6xxx/chip.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c index 72db6e74be48..c1bcd13af13f 100644 --- a/drivers/net/dsa/mv88e6xxx/chip.c +++ b/drivers/net/dsa/mv88e6xxx/chip.c @@ -2143,14 +2143,13 @@ static int mv88e6xxx_setup_message_port(struct mv88e6xxx_chip *chip, int port) static int mv88e6xxx_setup_egress_floods(struct mv88e6xxx_chip *chip, int port) { - struct dsa_switch *ds = chip->ds; - bool flood; - - /* Upstream ports flood frames with unknown unicast or multicast DA */ - flood = dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port); + /* Linux bridges are expected to flood unknown multicast and + * unicast frames to all ports - as per the defaults specified + * in the iproute2 bridge(8) man page. Not doing this causes + * stalls and failures with IPv6 over Marvell bridges. */ if (chip->info->ops->port_set_egress_floods) return chip->info->ops->port_set_egress_floods(chip, port, - flood, flood); + true, true); return 0; } -- 2.7.4