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 87F61C43381 for ; Sun, 17 Feb 2019 21:48:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3A5BD2080F for ; Sun, 17 Feb 2019 21:48:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="mdbX3Lol" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726314AbfBQVpo (ORCPT ); Sun, 17 Feb 2019 16:45:44 -0500 Received: from mail-pl1-f194.google.com ([209.85.214.194]:40887 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726124AbfBQVpo (ORCPT ); Sun, 17 Feb 2019 16:45:44 -0500 Received: by mail-pl1-f194.google.com with SMTP id bj4so7696210plb.7 for ; Sun, 17 Feb 2019 13:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+B0BUleue8PFYDI7uYbl+p9MSjrx7PkchTOaH0wA8sQ=; b=mdbX3LolVv27RnXYBOrM/Wx4HC9hLq9Y+xo1ER1WehLFiiymettrAE2JuimOuorE6w gwDUgjn5k1u/Od3PlyAogKHob7hbU1jq2QCV/kj5DLpw8fz8/1rSW/Z6DTReQmh/GjiV T3KIZODm2b2K6z3yDDT9Ab4wv9YgMwlweYrsmPorZd4yLtj9zSnRtJ1hW47btvzJ+4JV 9+An/Pct5PmCgAfBTLnzL2QKfZIv9mImz1uhCX5OKhFkvovNPeos+yX+lmWDgXzDUI5H 5UjDgH1IRhn3FUuuHrxXmU+zEoRUrbjVQERyE6JHQeAUOFn5RnGyTwRr4O2rHy9r9pQ7 B35Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=+B0BUleue8PFYDI7uYbl+p9MSjrx7PkchTOaH0wA8sQ=; b=uaKyDCnty7mMUFPvDk1HD6M66uZ1YkfsPKUWKv+k2z0vCLMwqoWEzU+H5t2OBNElCm OaJqbm84nXcH3xxBG6kH7zqjpXYb3SzcqzamtW+Ao5S4cLKE6RPt8wusjxROXoDiEwno 4bN0vrF46Pv666YS2WUsfwsej+J/nQMl2JrBiGj37KE3ExN37YlFZnVeW0jbHszpsG3Y 8Qp0FbZOKu9rr2ctoxwcDTidiNG0m8K0IHF7liSm86tv4nD5sAdRBZKsRpGdbAZ7+E5v 0/zCmFyFiFyE+nJbQEUfGa7Z17DYXmWriRr5rmumFGYTt/STBQG/Rmf5y1gdKngqiKZW D4EA== X-Gm-Message-State: AHQUAuYedJb/daK5r4VcPjTchHonN8E/rZ3p+Ch3RtkvRrup+NC5RTdw w0WUSDo0UtIs3sZKaUSzmTyhBbwB X-Google-Smtp-Source: AHgI3IaKNAbiTsJ03NdEucap1ghfe4+smsEGTZNQYffaqsaH7MKYUDUMgwF3Od32wf9z7PTJmBMM1w== X-Received: by 2002:a17:902:4503:: with SMTP id m3mr21795558pld.35.1550439942511; Sun, 17 Feb 2019 13:45:42 -0800 (PST) Received: from [192.168.1.3] (ip68-228-73-187.oc.oc.cox.net. [68.228.73.187]) by smtp.gmail.com with ESMTPSA id t24sm14499138pfh.21.2019.02.17.13.45.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Feb 2019 13:45:41 -0800 (PST) Subject: Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: defautl to multicast and unicast flooding To: Russell King - ARM Linux admin , Andrew Lunn , Vivien Didelot Cc: "David S. Miller" , netdev@vger.kernel.org References: <20190217142414.cjtmpi5y2l5rtdlb@shell.armlinux.org.uk> <20190217142716.gsrq5k2gnw3hsnhu@shell.armlinux.org.uk> <20190217163434.xo3ojbny4dnfqqwq@shell.armlinux.org.uk> From: Florian Fainelli Openpgp: preference=signencrypt Autocrypt: addr=f.fainelli@gmail.com; keydata= mQENBFPAG8ABCAC3EO02urEwipgbUNJ1r6oI2Vr/+uE389lSEShN2PmL3MVnzhViSAtrYxeT M0Txqn1tOWoIc4QUl6Ggqf5KP6FoRkCrgMMTnUAINsINYXK+3OLe7HjP10h2jDRX4Ajs4Ghs JrZOBru6rH0YrgAhr6O5gG7NE1jhly+EsOa2MpwOiXO4DE/YKZGuVe6Bh87WqmILs9KvnNrQ PcycQnYKTVpqE95d4M824M5cuRB6D1GrYovCsjA9uxo22kPdOoQRAu5gBBn3AdtALFyQj9DQ KQuc39/i/Kt6XLZ/RsBc6qLs+p+JnEuPJngTSfWvzGjpx0nkwCMi4yBb+xk7Hki4kEslABEB AAG0KEZsb3JpYW4gRmFpbmVsbGkgPGZhaW5lbGxpQGJyb2FkY29tLmNvbT6JAccEEAECALEF AlPAG9YXCgABv0jL/n0t8VEFmtDa8j7qERo7AN0gFAAAAAAAFgABa2V5LXVzYWdlLW1hc2tA cGdwLmNvbY4wFIAAAAAAIAAHcHJlZmVycmVkLWVtYWlsLWVuY29kaW5nQHBncC5jb21wZ3Bt aW1lCAsJCAcDAgEKAhkBBReAAAAAGRhsZGFwOi8va2V5cy5icm9hZGNvbS5jb20FGwMAAAAD FgIBBR4BAAAABBUICQoACgkQgTG1xCm8ZqD+Dgf9HhhzqvJYIPomNeg+ll7/TbzWb871E+HQ TaufJQFQwLEbgdFSZO2uj4UqfDpCyTwtHTVMJogWt3pCAE1sadeIY8OlT6918ofKIl8AiHj2 BlfL7ASZ5wzkRMt/4TZoinq9O1tPEynb5G6PdZTV3UQtmSGnpt2EOu7KtRJsnThBiXoOO9TJ Asg4vXJ0ZM1y/MPhQlZbPCHQZFe1gaVWBPLGnLyWyeprqgSLWHaGqrUhlfK1sLuJK1bjYDCI NetK0pS4cA4ZJgogr5FrtV64R19zLl02mt/Yj7rAmjC3ZBuwVi3V35kD8Kd4d9QM2apsiILV bzGbtVCSUgvxI+1SsJEm3bkBDQRTwBvBAQgArGvvWip77T4xgJztZp9YRylAcVTC9gtx0Gg6 eYk/EPANGm9TkuGpI++T/Il2H2TjFQNC7eubWohbYj0+6Tmf8nP+VmyobDxPXcMrK7x4xy9o D+Kub2Vf0SXbsM8fL/SqzGbFWZSm73L1L4GZoxvYIz0i7LExYSX2u5YVLaMBaH9HwKt2cvr7 MuTrRHtcbOZImoXT29g2UnoF1uwxYNeRhZY/lRvVkkY0lDipPuDwg3SpfHMtCybPq1uAswQd gEbHzRsEXwCR1OF3pIuGt4I3tSEhH/k1caqi0BlqjbGUOkku44xC2gf1ZU267FBBkdV3yJ/7 KnrJEnkMCYhS3kII9wARAQABiQJBBBgBAgErBQJTwBvCBRsMAAAAwF0gBBkBCAAGBQJTwBvB AAoJEJNgBqiYLw9VDRUIAJaTef6hsUAESnlGDpC+ymL2RZdzAJx9lXjU4hhaFcyhznuyyMJq d3mehmLxsqDRvHDiqyD71w2Bnc838MVZw0pwBPdnb/h9Ocmp0lL/9hwSGWvy4az5lYVyoA9u 14UIzh0YNGu6jr0isd/LJAbHXqwJwWWs3y8PTrpEp68V6lv+aXt5gR03lJEAvIR1Awp4JJ/e Z5y12gQISp0X8xal9YhhDWER92YLYrO2b6Hc2S31lAupzfCw8lmZsP1PRz1GmF/KmDD9J9N/ b8IehhWQqrBQjMjn2K2XkvN75HnAMHKFYfHZR3ZHtK52ZP1crV7THtbtrnPXVDq+vO4QPmdC +SEACgkQgTG1xCm8ZqC6BwgAl3kRh7oozpjpG8jpO8en5CBtTl3G+OpKJK9qbQyzdCsuJ0K1 qe1wZPZbP/Y+VtmqSgnExBzjStt9drjFBK8liPQZalp2sMlS9S7csSy6cMLF1auZubAZEqpm tpXagbtgR12YOo57Reb83F5KhtwwiWdoTpXRTx/nM0cHtjjrImONhP8OzVMmjem/B68NY++/ qt0F5XTsP2zjd+tRLrFh3W4XEcLt1lhYmNmbJR/l6+vVbWAKDAtcbQ8SL2feqbPWV6VDyVKh ya/EEq0xtf84qEB+4/+IjCdOzDD3kDZJo+JBkDnU3LBXw4WCw3QhOXY+VnhOn2EcREN7qdAK w0j9Sw== Message-ID: <1a956aeb-f195-90ca-a5a5-fabac450feac@gmail.com> Date: Sun, 17 Feb 2019 13:45:24 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190217163434.xo3ojbny4dnfqqwq@shell.armlinux.org.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 2/17/2019 8:34 AM, Russell King - ARM Linux admin wrote: > On Sun, Feb 17, 2019 at 02:27:16PM +0000, Russell King - ARM Linux admin wrote: >> On Sun, Feb 17, 2019 at 02:25:17PM +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 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. >> >> Note that there is the open question whether this affects the case where >> each port is used as a separate network interface: that case has not yet >> been tested. > > I've checked with a mv88e6131 on the clearfog gt8k board. lan1 > connected to my lan with plenty of traffic on, and configured as > part of a bridge. lan2 connected to the zii board, but not part > of the bridge. Monitoring lan2 from the zii board shows no traffic > that was received from lan1. > > So it looks fine. With the current state whereby we do not have the necessary hooks to perform filtering on non-bridged/standalone ports, this is entirely fine indeed. In the future this is part of something I want to address because it is IMHO highly undesirable to have non-bridged ports be flooded with unknown multicast or unknown unicast for that matter because that makes them deviate from a standard NIC interface. Unknown unicast is not necessarily a low hanging fruit, but still, if we have switches capable of filtering, we might as well make use of that. Of course, one difficulty is that we must not break running tcpdump on those DSA slave network interfaces. > >> >>> >>> Signed-off-by: Russell King >>> --- >>> drivers/net/dsa/mv88e6xxx/chip.c | 9 +++++---- >>> 1 file changed, 5 insertions(+), 4 deletions(-) >>> >>> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c >>> index b75a865a293d..eb5e3d88374f 100644 >>> --- a/drivers/net/dsa/mv88e6xxx/chip.c >>> +++ b/drivers/net/dsa/mv88e6xxx/chip.c >>> @@ -2144,13 +2144,14 @@ 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 >>> >>> >> >> -- >> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ >> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up >> According to speedtest.net: 11.9Mbps down 500kbps up > -- Florian