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=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 97D3DC43381 for ; Sun, 17 Feb 2019 22:03:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 52185217F9 for ; Sun, 17 Feb 2019 22:03:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="k13E6TOz" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726749AbfBQWDu (ORCPT ); Sun, 17 Feb 2019 17:03:50 -0500 Received: from mail-pf1-f194.google.com ([209.85.210.194]:41226 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726124AbfBQWDu (ORCPT ); Sun, 17 Feb 2019 17:03:50 -0500 Received: by mail-pf1-f194.google.com with SMTP id b7so7498982pfi.8 for ; Sun, 17 Feb 2019 14:03:49 -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=zgcah4yVecyCVRw82RjvZnz4ZrzWiNWS2+GQSZSEFZE=; b=k13E6TOzkpSk3vvctuKBOn+p2DJjJFJ8fEiXhJNuyeSKVUtYiZ8rHesTkLQn8u8iue KgYBQDo/i4GCnQ97bxicYkQKsMT+3/ZDuZs6a3lli0Pos62P3/6jfdWDAZn8ldvy05lx LvUYHE4ZO0YvxIaVdn1z9BlUbsJGanRVwycAFEjNI3bInZzlWvtV0A9az8n0rTtJnD6/ VaQa0AtgsdsLBfD6PXaNcyfmj/JmS9/B54MXMIJa/m7GXTQdrTBtNGf2NBr0cTx+aWtJ vJdwFwYdhR2sQVMLxbUXaSsIfVUb+HeukuM/cbxqkwkwLkOiRj9aQO38ANY9CbIAdTcp GBUg== 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=zgcah4yVecyCVRw82RjvZnz4ZrzWiNWS2+GQSZSEFZE=; b=aOOK9IobjEaAhoYvk5JBVoHiCARBC4jZTAt4aOVcjCDF5j+l3cRzyfEBiuuf/Hm7Py 0240w1w8eOOYVrROd8nG3c8aGND5EmMiB6jXR+6erDMKSyymjhx55qQTNLWD/s+nY2P6 o8JKPNoMoz3nNVEzbDfxzvgrudXkmzUvymgjmNj1pu3hKtOtezIQOLktKHcevyoAqeg9 JY1n8TXzJ27WZYZQXU8fI129hEJzS/O17Y2d5y3ClbPMoNbTiZ89wkecIdDVIhT+QSkt uxIK5B1NJGWhjAPmTj7xfsGEDNnLUspG762MqrPoGLbQFRyXYMUhLWW5taZtveu0YOCo 2HSQ== X-Gm-Message-State: AHQUAuZ84k7pUCgleiBSquNaRuRaKxXbKRY7wclrXIB03RvFq/P+bvy7 z45O1g4PGMSdX4y8NoStimbsyscy X-Google-Smtp-Source: AHgI3IbeRdELvdiPpElky2Ex8Yz0Et/YaUgY+hiBxAT/yavsPRVr1b4w8merFzCImNxhJsgb52qBTA== X-Received: by 2002:a62:f5c8:: with SMTP id b69mr15571053pfm.128.1550441028746; Sun, 17 Feb 2019 14:03:48 -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 b15sm21860458pfj.44.2019.02.17.14.03.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Feb 2019 14:03:47 -0800 (PST) Subject: Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: defautl to multicast and unicast flooding To: Russell King - ARM Linux admin Cc: Andrew Lunn , Vivien Didelot , "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> <1a956aeb-f195-90ca-a5a5-fabac450feac@gmail.com> <20190217215827.2iavpy4xyh3viqup@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: <39dbb59c-0c67-95f8-6703-d3e628d8c50e@gmail.com> Date: Sun, 17 Feb 2019 14:03:40 -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: <20190217215827.2iavpy4xyh3viqup@shell.armlinux.org.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 2/17/2019 1:58 PM, Russell King - ARM Linux admin wrote: > On Sun, Feb 17, 2019 at 01:45:24PM -0800, Florian Fainelli wrote: >> >> >> 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. > > Sorry, I think you have the wrong end of the stick. > > For a non-bridged port, I am seeing _no_ traffic apart from that > explicitly sent out through that port. In other words, there are > _no_ flooded frames coming out of the non-bridged port. > > This patch appears to have no material effect on non-bridged ports. Presumably because that non-bridged port and the CPU port are part of the same domain with only those 2 ports and that is what we want. Now what happens if say you have a station that sends multicast traffic through that port to e.g.: 226.94.1.1, I bet that port happily sends that multicast traffic to the CPU port with no filtering what so ever and this ends-up being dropped in the network stack because there is a socket look up failure there. IMHO unless you have a receiver/server on that network interface on the DSA network interface and a matching socket you should not be receiving that multicast traffic and the switch should be filtering it. Since the network stack will call into ndo_set_rx_mode() for those cases, we really just need to make that multicast traffic known, instead of unknown to the switch. -- Florian