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.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 119E7C43381 for ; Wed, 20 Feb 2019 22:29:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D0F6A20836 for ; Wed, 20 Feb 2019 22:29:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TRQYsZCD" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726848AbfBTW3q (ORCPT ); Wed, 20 Feb 2019 17:29:46 -0500 Received: from mail-qk1-f177.google.com ([209.85.222.177]:41637 "EHLO mail-qk1-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725804AbfBTW3q (ORCPT ); Wed, 20 Feb 2019 17:29:46 -0500 Received: by mail-qk1-f177.google.com with SMTP id y15so1651661qki.8 for ; Wed, 20 Feb 2019 14:29:45 -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=l9NWKQH5nQEnyhz6tKDjCCPSKJ/WQ3BXcNMwA/D+0js=; b=TRQYsZCDWA6V4xzTZak6mRZ9qeOG+SYrJkfQn9HAB0bh8twIOP+wVOe2ZOGDJkT7Zc vyfZ+ld1tfT2/vOc4u8RfuDR4z54/zw10y4aNH1H3abLuIXD4iIM8y5+/Rs47Hig0v9x K5SMXHUNJsB7356yaL4/3QW/556ZosvROJYL5goBRVtbt/mU6GCyEBix1Bi72NZRxouV d3SHXufxOCf6QMncJf/Qz5H4EI1YofkJDv8lFq1cIAjN9z6yFlSVWT6TC2fPk7phFbi9 6YkLrGnA6x/2pOe56+OXPWtK57+DcWK4+pOo4zXh93JUaAKzdz3qYajR71DxBLElzFy0 hKBQ== 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=l9NWKQH5nQEnyhz6tKDjCCPSKJ/WQ3BXcNMwA/D+0js=; b=thY+wVBlE0tyj78MQJkROdpYX7p5p29xzM+Hz4Sss5kd81vIiDBjjoT4nlthS4Cgkl N1ajjW23hbAFAQZShdroQQb08Ur4KAzDSJh5qEQOOSPCd+8g9W31IFmFpCGcPBwfMfJ8 JM6810m6nezTEoXI9Iz/wsrFdrrpas8UoTibOBMq8v4/gpTZgufIgfK2g/3coi1tff05 BXnMNx36ZhNX4zYxcaLlsNP2u3yxqGe3jt7v8pJFHFc2j+8fut5FWkJ1med2tCIlfwTc IMbD12sqmupjK0iAfctbXnhdYadIHbkyYWM7Oz0wgeMqThmSnrzsXxQbMW9VO3Mb7cb2 a3aQ== X-Gm-Message-State: AHQUAuZrbACpmOQylwLq2o+xuD7QGHRJJnOJUMNvxrvVaklEW0Lyk6uy hcmFxl59CjeBIBYVVHXA8gM= X-Google-Smtp-Source: AHgI3IYHd+P69ZqKJP4QzKFUZUjiRr0qrkU6a5/pYLLpR0tqmndCN5Ydy3VJIWP/d32CD5dtJdjV9A== X-Received: by 2002:a37:6314:: with SMTP id x20mr26546863qkb.276.1550701784672; Wed, 20 Feb 2019 14:29:44 -0800 (PST) Received: from localhost (modemcable249.105-163-184.mc.videotron.ca. [184.163.105.249]) by smtp.gmail.com with ESMTPSA id g189sm11396312qkb.3.2019.02.20.14.29.43 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 20 Feb 2019 14:29:43 -0800 (PST) Date: Wed, 20 Feb 2019 17:29:43 -0500 Message-ID: <20190220172943.GD9484@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 v4 3/3] net: dsa: enable flooding for bridge ports In-Reply-To: References: <20190220205525.nji63ntsthxbus4l@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 On Wed, 20 Feb 2019 20:56:04 +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 Reviewed-by: Vivien Didelot