[{"id":1763733,"web_url":"http://patchwork.ozlabs.org/comment/1763733/","msgid":"<20170905171141.7040519b@xeon-e3>","list_archive_url":null,"date":"2017-09-06T00:11:41","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":21389,"url":"http://patchwork.ozlabs.org/api/people/21389/","name":"Stephen Hemminger","email":"stephen@networkplumber.org"},"content":"On Wed, 6 Sep 2017 01:35:02 +0200\nAndrew Lunn wrote:\n\n> After the very useful feedback from Nikolay, i threw away what i had,\n> and started again. To recap:\n> \n> The linux bridge supports IGMP snooping. It will listen to IGMP\n> reports on bridge ports and keep track of which groups have been\n> joined on an interface. It will then forward multicast based on this\n> group membership.\n> \n> When the bridge adds or removed groups from an interface, it uses\n> switchdev to request the hardware add an mdb to a port, so the\n> hardware can perform the selective forwarding between ports.\n> \n> What is not covered by the current bridge code, is IGMP joins/leaves\n> from the host on the brX interface. These are not reported via\n> switchdev so that hardware knows the local host is interested in the\n> multicast frames.\n> \n> Luckily, the bridge does track joins/leaves on the brX interface. The\n> code is obfusticated, which is why i missed it with my first attempt.\n> So the first patch tries to remove this obfustication. Currently,\n> there is no notifications sent when the bridge interface joins a\n> group. The second patch adds them. bridge monitor then shows\n> joins/leaves in the same way as for other ports of the bridge.\n> \n> Then starts the work passing down to the hardware that the host has\n> joined/left a group. The existing switchdev mdb object cannot be used,\n> since the semantics are different. The existing\n> SWITCHDEV_OBJ_ID_PORT_MDB is used to indicate a specific multicast\n> group should be forwarded out that port of the switch. However here we\n> require the exact opposite. We want multicast frames for the group\n> received on the port to the forwarded to the host. Hence add a new\n> object SWITCHDEV_OBJ_ID_HOST_MDB, a multicast database entry to\n> forward to the host. This new object is then propagated through the\n> DSA layers. No DSA driver changes should be needed, this should just\n> work...\n> \n> Getting the frames to the bridge as requested turned up an issue or\n> three. The offload_fwd_mark is not being set by DSA, so the bridge\n> floods the received frames back to the switch ports, resulting in\n> duplication since the hardware has already flooded the packet. Fixing\n> that turned up an issue with the meaning of\n> SWITCHDEV_ATTR_ID_PORT_PARENT_ID in DSA. A DSA fabric of three\n> switches needs to look to the software bridge as a single\n> switch. Otherwise the offload_fwd_mark does not work, and we get\n> duplication on the non-ingress switch. But each switch returned a\n> different value. And they were not unique.\n> \n> The third and last issue will be explained in a followup email.\n> \n> Open questions:\n> \n> Is sending notifications going to break userspace?\n> Is this new switchdev object O.K. for the few non-DSA switches that exist?\n> Is the SWITCHDEV_ATTR_ID_PORT_PARENT_ID change acceptable?\n> \n> Andrew\n> \n> Andrew Lunn (8):\n> net: bridge: Rename mglist to host_joined\n> net: bridge: Send notification when host join/leaves a group\n> net: bridge: Add/del switchdev object on host join/leave\n> net: dsa: slave: Handle switchdev host mdb add/del\n> net: dsa: switch: handle host mdb add/remove\n> net: dsa: switch: Don't add CPU port to an mdb by default\n> net: dsa: set offload_fwd_mark on received packets\n> net: dsa: Fix SWITCHDEV_ATTR_ID_PORT_PARENT_ID\n> \n> include/net/switchdev.h | 1 +\n> net/bridge/br_input.c | 2 +-\n> net/bridge/br_mdb.c | 50 +++++++++++++++++++++++++++++---\n> net/bridge/br_multicast.c | 18 +++++++-----\n> net/bridge/br_private.h | 2 +-\n> net/dsa/dsa.c | 1 +\n> net/dsa/dsa_priv.h | 7 +++++\n> net/dsa/port.c | 26 +++++++++++++++++\n> net/dsa/slave.c | 16 ++++++++---\n> net/dsa/switch.c | 72 +++++++++++++++++++++++++++++++++++++++--------\n> net/switchdev/switchdev.c | 2 ++\n> 11 files changed, 168 insertions(+), 29 deletions(-)\n> \n\nThis looks much cleaner. I don't have DSA hardware or infrastructure to look deeper.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=networkplumber-org.20150623.gappssmtp.com\n\theader.i=@networkplumber-org.20150623.gappssmtp.com\n\theader.b=\"syvlymhs\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xn3t20Fgpz9sNc\n\tfor ;\n\tWed, 6 Sep 2017 10:11:54 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754255AbdIFALu (ORCPT );\n\tTue, 5 Sep 2017 20:11:50 -0400","from mail-pg0-f45.google.com ([74.125.83.45]:38889 \"EHLO\n\tmail-pg0-f45.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1753614AbdIFALt (ORCPT\n\t); Tue, 5 Sep 2017 20:11:49 -0400","by mail-pg0-f45.google.com with SMTP id v66so12144882pgb.5\n\tfor ; Tue, 05 Sep 2017 17:11:48 -0700 (PDT)","from xeon-e3 (76-14-207-240.or.wavecable.com. [76.14.207.240])\n\tby smtp.gmail.com with ESMTPSA id w4sm171046pfa.8.2017.09.05.17.11.48\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tTue, 05 Sep 2017 17:11:48 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=networkplumber-org.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:in-reply-to:references\n\t:mime-version:content-transfer-encoding;\n\tbh=0XDnHDKBBAAQeCgOnr4XSvLIc0/+N4AVChe6MHQWxqA=;\n\tb=syvlymhsiKYdhGR+/MXUdpjiKg/uJ50Jpfo8Ynd1oLC6lbxehukiTwZWwPCtgLACO6\n\tZu4O2lxrGoOjnpFUA5SzknaBOV8tMhQV47iFM6pTCvASBo/T7pYq9OxSwoRWiY2h565C\n\tpeNG5rzkmmgH9Yl5tiQAegdE4L3gOCc74GAOfW1I2nseMCD52Yt7v1fqtbYpCRmZvt4j\n\tgSyb/ZrW3ely2wPtBZ0lxSoQmR91w23dZJ9YNYqzVFP8qDJmPfywLW7h3eI82AfHdPpk\n\tuKIHmWYLpue710ZP6UHvg/sXCTmrXs3LuNVIlQajG8n5qEzuaSr2QNOZehmn4iPc7Js+\n\twA2w==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to\n\t:references:mime-version:content-transfer-encoding;\n\tbh=0XDnHDKBBAAQeCgOnr4XSvLIc0/+N4AVChe6MHQWxqA=;\n\tb=USWbB3FaYYnx7711GbLA95iD1PZ5bnz5+VdcaFETiY2AJ3K1rMehXZ50ZHbNTv6Gvx\n\tmgIRwve9RwlcGtuBzcCdYm+6qcD/H4YWkYOLwKX8Yy1eolMQWSivLB1NrtHPoCaB6Z6f\n\taraP2NHtwgtgEL9Va5Y/1RIV9sN8epYy3xCjbJGcaIaKM2ZHa1adbSeuTAuSTW7u4gDE\n\tlJ1HRVouhSI+f4RbKUR40iX7W0mW/7KQpcQ/Z8GYQmHrOnK9qCgHyhtyxprNAi5bS3A3\n\twbRX370w1i7RnAs1iolsfpzhzUretGGL4u4CsqJgGEnwb6lnDtduQn3yyJYUo6ZX90pq\n\tiSXQ==","X-Gm-Message-State":"AHPjjUhPPZ8RMDDOMcduHLQF/YS9H3ujPX780dnbFaihmmnBDMpwwSaL\n\tOIyufJ3d42nYxG1v","X-Google-Smtp-Source":"ADKCNb6vpYZ9WNqgkQ+HyZWLjod0vatRWEcApBJHUyVcKnm7qRRQG8uFIQ+oN4kp61/3rAnFbGd2ew==","X-Received":"by 10.84.213.150 with SMTP id g22mr6239376pli.313.1504656708537; \n\tTue, 05 Sep 2017 17:11:48 -0700 (PDT)","Date":"Tue, 5 Sep 2017 17:11:41 -0700","From":"Stephen Hemminger ","To":"Andrew Lunn ","Cc":"netdev , jiri@resnulli.us,\n\tnikolay@cumulusnetworks.com, Florian Fainelli ,\n\tVivien Didelot ","Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","Message-ID":"<20170905171141.7040519b@xeon-e3>","In-Reply-To":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1763751,"web_url":"http://patchwork.ozlabs.org/comment/1763751/","msgid":"<20170906004703.GB27385@lunn.ch>","list_archive_url":null,"date":"2017-09-06T00:47:03","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"> The third and last issue will be explained in a followup email.\n\nHi DSA hackers\n\nSo there is the third issue. It affects just DSA, but it possible\naffects all DSA drivers.\n\nThis patchset broken broadcast with the Marvell drivers. It could\nbreak broadcast on others drivers as well.\n\nWhat i found is that the Marvell chips don't flood broadcast frames\nbetween bridged ports. What appears to happen is there is a fdb miss,\nso it gets forwarded to the CPU port for the host to deal with. The\nsoftware bridge when floods it out all ports of the bridge.\n\nBut the set offload_fwd_mark patch changes this. The software bridge\nnow assumes the hardware has already flooded broadcast out all ports\nof the switch as needed. So it does not do any flooding itself. As a\nresult, on Marvell devices, broadcast packets don't get flooded at\nall.\n\nThe issue can be fixed. I just need to add an mdb entry for the\nbroadcast address to each port of the bridge in the switch, and the\nCPU port. But i don't know at what level to do this.\n\nShould this be done at the DSA level, or at the driver level? Do any\nchips do broadcast flooding in hardware already? Hence they currently\nsee broadcast duplication? If i add a broadcast mdb at the DSA level,\nand the chip is already hard wired to flooding broadcast, is it going\nto double flood?\n\n\tAndrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xn4fv445qz9sR9\n\tfor ;\n\tWed, 6 Sep 2017 10:47:19 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753116AbdIFArQ (ORCPT );\n\tTue, 5 Sep 2017 20:47:16 -0400","from vps0.lunn.ch ([178.209.37.122]:58290 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1753087AbdIFArO (ORCPT );\n\tTue, 5 Sep 2017 20:47:14 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dpOUh-0008SP-JN; Wed, 06 Sep 2017 02:47:03 +0200"],"Date":"Wed, 6 Sep 2017 02:47:03 +0200","From":"Andrew Lunn ","To":"netdev , Florian Fainelli ,\n\tVivien Didelot ,\n\tWoojung.Huh@microchip.com, jbe@pengutronix.de,\n\tsean.wang@mediatek.com, john@phrozen.org","Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","Message-ID":"<20170906004703.GB27385@lunn.ch>","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1763967,"web_url":"http://patchwork.ozlabs.org/comment/1763967/","msgid":"<4ef8c5d7-4a2b-80eb-65ee-53d6c1631924@cumulusnetworks.com>","list_archive_url":null,"date":"2017-09-06T09:52:32","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":66448,"url":"http://patchwork.ozlabs.org/api/people/66448/","name":"Nikolay Aleksandrov","email":"nikolay@cumulusnetworks.com"},"content":"On 06/09/17 03:11, Stephen Hemminger wrote:\n> On Wed, 6 Sep 2017 01:35:02 +0200\n> Andrew Lunn wrote:\n> \n>> After the very useful feedback from Nikolay, i threw away what i had,\n>> and started again. To recap:\n>>\n>> The linux bridge supports IGMP snooping. It will listen to IGMP\n>> reports on bridge ports and keep track of which groups have been\n>> joined on an interface. It will then forward multicast based on this\n>> group membership.\n>>\n>> When the bridge adds or removed groups from an interface, it uses\n>> switchdev to request the hardware add an mdb to a port, so the\n>> hardware can perform the selective forwarding between ports.\n>>\n>> What is not covered by the current bridge code, is IGMP joins/leaves\n>> from the host on the brX interface. These are not reported via\n>> switchdev so that hardware knows the local host is interested in the\n>> multicast frames.\n>>\n>> Luckily, the bridge does track joins/leaves on the brX interface. The\n>> code is obfusticated, which is why i missed it with my first attempt.\n>> So the first patch tries to remove this obfustication. Currently,\n>> there is no notifications sent when the bridge interface joins a\n>> group. The second patch adds them. bridge monitor then shows\n>> joins/leaves in the same way as for other ports of the bridge.\n>>\n>> Then starts the work passing down to the hardware that the host has\n>> joined/left a group. The existing switchdev mdb object cannot be used,\n>> since the semantics are different. The existing\n>> SWITCHDEV_OBJ_ID_PORT_MDB is used to indicate a specific multicast\n>> group should be forwarded out that port of the switch. However here we\n>> require the exact opposite. We want multicast frames for the group\n>> received on the port to the forwarded to the host. Hence add a new\n>> object SWITCHDEV_OBJ_ID_HOST_MDB, a multicast database entry to\n>> forward to the host. This new object is then propagated through the\n>> DSA layers. No DSA driver changes should be needed, this should just\n>> work...\n>>\n>> Getting the frames to the bridge as requested turned up an issue or\n>> three. The offload_fwd_mark is not being set by DSA, so the bridge\n>> floods the received frames back to the switch ports, resulting in\n>> duplication since the hardware has already flooded the packet. Fixing\n>> that turned up an issue with the meaning of\n>> SWITCHDEV_ATTR_ID_PORT_PARENT_ID in DSA. A DSA fabric of three\n>> switches needs to look to the software bridge as a single\n>> switch. Otherwise the offload_fwd_mark does not work, and we get\n>> duplication on the non-ingress switch. But each switch returned a\n>> different value. And they were not unique.\n>>\n>> The third and last issue will be explained in a followup email.\n>>\n>> Open questions:\n>>\n>> Is sending notifications going to break userspace?\n>> Is this new switchdev object O.K. for the few non-DSA switches that exist?\n>> Is the SWITCHDEV_ATTR_ID_PORT_PARENT_ID change acceptable?\n>>\n>> Andrew\n>>\n>> Andrew Lunn (8):\n>> net: bridge: Rename mglist to host_joined\n>> net: bridge: Send notification when host join/leaves a group\n>> net: bridge: Add/del switchdev object on host join/leave\n>> net: dsa: slave: Handle switchdev host mdb add/del\n>> net: dsa: switch: handle host mdb add/remove\n>> net: dsa: switch: Don't add CPU port to an mdb by default\n>> net: dsa: set offload_fwd_mark on received packets\n>> net: dsa: Fix SWITCHDEV_ATTR_ID_PORT_PARENT_ID\n>>\n>> include/net/switchdev.h | 1 +\n>> net/bridge/br_input.c | 2 +-\n>> net/bridge/br_mdb.c | 50 +++++++++++++++++++++++++++++---\n>> net/bridge/br_multicast.c | 18 +++++++-----\n>> net/bridge/br_private.h | 2 +-\n>> net/dsa/dsa.c | 1 +\n>> net/dsa/dsa_priv.h | 7 +++++\n>> net/dsa/port.c | 26 +++++++++++++++++\n>> net/dsa/slave.c | 16 ++++++++---\n>> net/dsa/switch.c | 72 +++++++++++++++++++++++++++++++++++++++--------\n>> net/switchdev/switchdev.c | 2 ++\n>> 11 files changed, 168 insertions(+), 29 deletions(-)\n>>\n> \n> This looks much cleaner. I don't have DSA hardware or infrastructure to look deeper.\n> \n\n+1\n\nThis version looks great!","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=cumulusnetworks.com\n\theader.i=@cumulusnetworks.com header.b=\"GOBati6P\"; \n\tdkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnJm83F5Dz9sCZ\n\tfor ;\n\tWed, 6 Sep 2017 19:52:40 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752505AbdIFJwi (ORCPT );\n\tWed, 6 Sep 2017 05:52:38 -0400","from mail-wm0-f51.google.com ([74.125.82.51]:33263 \"EHLO\n\tmail-wm0-f51.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752319AbdIFJwh (ORCPT\n\t); Wed, 6 Sep 2017 05:52:37 -0400","by mail-wm0-f51.google.com with SMTP id f145so15705915wme.0\n\tfor ; Wed, 06 Sep 2017 02:52:36 -0700 (PDT)","from [192.168.0.103] (46-10-142-144.ip.btc-net.bg. [46.10.142.144])\n\tby smtp.googlemail.com with ESMTPSA id\n\ti131sm555197wmf.31.2017.09.06.02.52.33\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tWed, 06 Sep 2017 02:52:34 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=cumulusnetworks.com; s=google;\n\th=subject:to:references:cc:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=1FwXl36GrTN50RJbyOszAMFBGtWJEwqXCo6NjE4HFT4=;\n\tb=GOBati6PLLhZufCy70s3D4E21BvH1GULIyqQNTFB4FEiS1dGznUxakvFMKuwwu/tzB\n\trhHj0REF39me8OtRvCb4aDcbPE6LOKvEFbf7vpuGy6GgImNV6t3Ta/B79me5vIzWEwNk\n\t55/vE4c54STuFNlmi5/+K2zt1VhdJwsnYLvcE=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:cc:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=1FwXl36GrTN50RJbyOszAMFBGtWJEwqXCo6NjE4HFT4=;\n\tb=GzqdiKmPEC3mCzDQ/8R6lUZXcICvf8iL0f4xIcb+25w/6UVc2J3UMFpFY7Xe+0PuaF\n\tJqa338tSIrDkGpFTcoxE4GuxsKlBGpStc7kr46kQMeFw138mG0PGsJaNk3rj52p3woXg\n\t1tlyTmGs33vuta2XAPnLVAOaOYpeywcbV7nbTN60fWhEs4f5vFX8htauUr3BBnJOwAtL\n\tfPeUJPkaA0+qFYd+aJKGOt48Wpjb1WEPkXKIHtca94O80OGQHJ09Qe2VctDIEUeXUEAX\n\t5AyUPy86BiqDPNzhoFexwKaWsgbWHtieaZLMJ0ipz6hrdeL8aX98aJsgCm9/UTTthLBZ\n\tLcTA==","X-Gm-Message-State":"AHPjjUgVw9NO4xH4jR54v2AdRBL67PuBnxgqRsVPFi/S3GF2xYqPn8xb\n\tRRalIxU92HdT22iU","X-Google-Smtp-Source":"ADKCNb6rxjYckYjI1NlA9fNyz0ShrOyKDQDv7gwXSsSiEhgXR+QYm9lCfN5jrf/VJc/Ob58DgD87cw==","X-Received":"by 10.28.73.134 with SMTP id w128mr1271657wma.141.1504691555540; \n\tWed, 06 Sep 2017 02:52:35 -0700 (PDT)","Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","To":"Stephen Hemminger ,\n\tAndrew Lunn ","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>\n\t<20170905171141.7040519b@xeon-e3>","Cc":"netdev , jiri@resnulli.us,\n\tFlorian Fainelli ,\n\tVivien Didelot ","From":"Nikolay Aleksandrov ","Message-ID":"<4ef8c5d7-4a2b-80eb-65ee-53d6c1631924@cumulusnetworks.com>","Date":"Wed, 6 Sep 2017 12:52:32 +0300","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tIcedove/45.6.0","MIME-Version":"1.0","In-Reply-To":"<20170905171141.7040519b@xeon-e3>","Content-Type":"text/plain; charset=windows-1252","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1764127,"web_url":"http://patchwork.ozlabs.org/comment/1764127/","msgid":"<87y3pskk1p.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>","list_archive_url":null,"date":"2017-09-06T13:56:18","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":15889,"url":"http://patchwork.ozlabs.org/api/people/15889/","name":"Vivien Didelot","email":"vivien.didelot@savoirfairelinux.com"},"content":"Hi Andrew,\n\nAndrew Lunn writes:\n\n> So there is the third issue. It affects just DSA, but it possible\n> affects all DSA drivers.\n>\n> This patchset broken broadcast with the Marvell drivers. It could\n> break broadcast on others drivers as well.\n>\n> What i found is that the Marvell chips don't flood broadcast frames\n> between bridged ports. What appears to happen is there is a fdb miss,\n> so it gets forwarded to the CPU port for the host to deal with. The\n> software bridge when floods it out all ports of the bridge.\n\nDo you have this issue on a single switch?\n\nI do expect FDB (not MDB) miss on a multi-chip fabric, not on a single\nchip though.\n\n> But the set offload_fwd_mark patch changes this. The software bridge\n> now assumes the hardware has already flooded broadcast out all ports\n> of the switch as needed. So it does not do any flooding itself. As a\n> result, on Marvell devices, broadcast packets don't get flooded at\n> all.\n>\n> The issue can be fixed. I just need to add an mdb entry for the\n> broadcast address to each port of the bridge in the switch, and the\n> CPU port. But i don't know at what level to do this.\n>\n> Should this be done at the DSA level, or at the driver level? Do any\n> chips do broadcast flooding in hardware already? Hence they currently\n> see broadcast duplication? If i add a broadcast mdb at the DSA level,\n> and the chip is already hard wired to flooding broadcast, is it going\n> to double flood?\n\nIt should be done at the DSA level. DSA core must be the single entry\npoint to handle all the switch logic, calling into (dumb) DSA drivers.\nIf it is buried into a specific driver, we'll likely lose track of the\nproblem and make it harder to maintain.\n\n\nThanks!\n\n Vivien","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnQFK5frRz9s9Y\n\tfor ;\n\tWed, 6 Sep 2017 23:59:49 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S932363AbdIFN7r (ORCPT );\n\tWed, 6 Sep 2017 09:59:47 -0400","from mail.savoirfairelinux.com ([208.88.110.44]:54472 \"EHLO\n\tmail.savoirfairelinux.com\" rhost-flags-OK-OK-OK-OK) by\n\tvger.kernel.org with ESMTP id S932251AbdIFN7n (ORCPT\n\t); Wed, 6 Sep 2017 09:59:43 -0400","from localhost (localhost [127.0.0.1])\n\tby mail.savoirfairelinux.com (Postfix) with ESMTP id DBDC39C206B;\n\tWed, 6 Sep 2017 09:59:42 -0400 (EDT)","from mail.savoirfairelinux.com ([127.0.0.1])\n\tby localhost (mail.savoirfairelinux.com [127.0.0.1]) (amavisd-new,\n\tport 10032)\n\twith ESMTP id q2MELx9ViMtA; Wed, 6 Sep 2017 09:59:41 -0400 (EDT)","from localhost (localhost [127.0.0.1])\n\tby mail.savoirfairelinux.com (Postfix) with ESMTP id 693CA9C209E;\n\tWed, 6 Sep 2017 09:59:41 -0400 (EDT)","from mail.savoirfairelinux.com ([127.0.0.1])\n\tby localhost (mail.savoirfairelinux.com [127.0.0.1]) (amavisd-new,\n\tport 10026)\n\twith ESMTP id cM5H70Hm9qkQ; Wed, 6 Sep 2017 09:59:41 -0400 (EDT)","from localhost (modemcable249.105-163-184.mc.videotron.ca\n\t[184.163.105.249])\n\tby mail.savoirfairelinux.com (Postfix) with ESMTPSA id 34F679C206B;\n\tWed, 6 Sep 2017 09:59:41 -0400 (EDT)"],"X-Virus-Scanned":"amavisd-new at mail.savoirfairelinux.com","From":"Vivien Didelot ","To":"Andrew Lunn , netdev ,\n\tFlorian Fainelli ,\n\tWoojung.Huh@microchip.com, jbe@pengutronix.de,\n\tsean.wang@mediatek.com, john@phrozen.org","Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","In-Reply-To":"<20170906004703.GB27385@lunn.ch>","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>\n\t<20170906004703.GB27385@lunn.ch>","Date":"Wed, 06 Sep 2017 09:56:18 -0400","Message-ID":"<87y3pskk1p.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>","MIME-Version":"1.0","Content-Type":"text/plain","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1764137,"web_url":"http://patchwork.ozlabs.org/comment/1764137/","msgid":"<20170906141624.GE11864@lunn.ch>","list_archive_url":null,"date":"2017-09-06T14:16:24","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"> > What i found is that the Marvell chips don't flood broadcast frames\n> > between bridged ports. What appears to happen is there is a fdb miss,\n> > so it gets forwarded to the CPU port for the host to deal with. The\n> > software bridge when floods it out all ports of the bridge.\n> \n> Do you have this issue on a single switch?\n\nYes. I have two boards with a single switch in my test setup. They\nfail the broadcast tests in the same way as boards with multiple\nswitches.\n\n> It should be done at the DSA level. DSA core must be the single entry\n> point to handle all the switch logic, calling into (dumb) DSA drivers.\n> If it is buried into a specific driver, we'll likely lose track of the\n> problem and make it harder to maintain.\n\nI think we need to wait and see what driver writers report their chips\nare doing. If this is just a Marvell issue, we probably should fix it\nin the Marvell driver only.\n\nIf i remember correctly, Woojung said he was seeing duplication of\nbroadcasts. So it could be the Microchip hardware is forwarding\nbroadcast in the hardware.\n\n\t Andrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnQcb00TTz9s7f\n\tfor ;\n\tThu, 7 Sep 2017 00:16:30 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S932416AbdIFOQ2 (ORCPT );\n\tWed, 6 Sep 2017 10:16:28 -0400","from vps0.lunn.ch ([178.209.37.122]:58708 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S932284AbdIFOQ1 (ORCPT );\n\tWed, 6 Sep 2017 10:16:27 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dpb7w-0003pU-7D; Wed, 06 Sep 2017 16:16:24 +0200"],"Date":"Wed, 6 Sep 2017 16:16:24 +0200","From":"Andrew Lunn ","To":"Vivien Didelot ","Cc":"netdev , Florian Fainelli ,\n\tWoojung.Huh@microchip.com, jbe@pengutronix.de,\n\tsean.wang@mediatek.com, john@phrozen.org","Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","Message-ID":"<20170906141624.GE11864@lunn.ch>","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>\n\t<20170906004703.GB27385@lunn.ch>\n\t<87y3pskk1p.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<87y3pskk1p.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1764148,"web_url":"http://patchwork.ozlabs.org/comment/1764148/","msgid":"<2c1d26b4-fbb2-3346-ca35-86b4f635b60a@phrozen.org>","list_archive_url":null,"date":"2017-09-06T14:27:05","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":7496,"url":"http://patchwork.ozlabs.org/api/people/7496/","name":"John Crispin","email":"john@phrozen.org"},"content":"On 06/09/17 02:47, Andrew Lunn wrote:\n> Should this be done at the DSA level, or at the driver level? Do any\n> chips do broadcast flooding in hardware already? Hence they currently\n> see broadcast duplication? If i add a broadcast mdb at the DSA level,\n> and the chip is already hard wired to flooding broadcast, is it going\n> to double flood?\n\nHi Andrew,\n\nMT7530 and QCA8K only have a \"unknown mac fwd to port X\" feature. both \nuse the same HW table for FDB and MDB tables. so this should ideally be \nfixed on DSA level rather than fixing up those 2 drivers.\n\n John","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnQsZ4RFnz9t4t\n\tfor ;\n\tThu, 7 Sep 2017 00:27:46 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S932411AbdIFO1o (ORCPT );\n\tWed, 6 Sep 2017 10:27:44 -0400","from nbd.name ([46.4.11.11]:59840 \"EHLO nbd.name\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S932260AbdIFO1n (ORCPT );\n\tWed, 6 Sep 2017 10:27:43 -0400"],"Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","To":"Andrew Lunn , netdev ,\n\tFlorian Fainelli ,\n\tVivien Didelot ,\n\tWoojung.Huh@microchip.com, jbe@pengutronix.de, sean.wang@mediatek.com","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>\n\t<20170906004703.GB27385@lunn.ch>","From":"John Crispin ","Message-ID":"<2c1d26b4-fbb2-3346-ca35-86b4f635b60a@phrozen.org>","Date":"Wed, 6 Sep 2017 16:27:05 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170906004703.GB27385@lunn.ch>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"7bit","Content-Language":"en-US","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1764153,"web_url":"http://patchwork.ozlabs.org/comment/1764153/","msgid":"<87vakvlx2b.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>","list_archive_url":null,"date":"2017-09-06T14:29:48","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":15889,"url":"http://patchwork.ozlabs.org/api/people/15889/","name":"Vivien Didelot","email":"vivien.didelot@savoirfairelinux.com"},"content":"Hi Andrew,\n\nAndrew Lunn writes:\n\n> Getting the frames to the bridge as requested turned up an issue or\n> three. The offload_fwd_mark is not being set by DSA, so the bridge\n> floods the received frames back to the switch ports, resulting in\n> duplication since the hardware has already flooded the packet. Fixing\n> that turned up an issue with the meaning of\n> SWITCHDEV_ATTR_ID_PORT_PARENT_ID in DSA. A DSA fabric of three\n> switches needs to look to the software bridge as a single\n> switch. Otherwise the offload_fwd_mark does not work, and we get\n> duplication on the non-ingress switch. But each switch returned a\n> different value. And they were not unique.\n\n[...]\n\n> Is the SWITCHDEV_ATTR_ID_PORT_PARENT_ID change acceptable?\n\nSo here we need to return the switch fabric (tree) ID instead of a\nsingle switch chip ID. I think we are not supposed to change it, but\nthere's definitly something wrong with them and we must fix it.\n\nThe same issue happens with the physical port IDs, where the net devices\nof two disjoint trees on a system will have the same phys_*_id\nattributes, because we do not include the tree ID in them.\n\n(not sure if this affects your patchset though.)\n\n\nThanks,\n\n Vivien","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnQzv3pRhz9t4t\n\tfor ;\n\tThu, 7 Sep 2017 00:33:15 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S932511AbdIFOdN (ORCPT );\n\tWed, 6 Sep 2017 10:33:13 -0400","from mail.savoirfairelinux.com ([208.88.110.44]:57000 \"EHLO\n\tmail.savoirfairelinux.com\" rhost-flags-OK-OK-OK-OK) by\n\tvger.kernel.org with ESMTP id S1754821AbdIFOdM (ORCPT\n\t); Wed, 6 Sep 2017 10:33:12 -0400","from localhost (localhost [127.0.0.1])\n\tby mail.savoirfairelinux.com (Postfix) with ESMTP id 98A889C206B;\n\tWed, 6 Sep 2017 10:33:11 -0400 (EDT)","from mail.savoirfairelinux.com ([127.0.0.1])\n\tby localhost (mail.savoirfairelinux.com [127.0.0.1]) (amavisd-new,\n\tport 10032)\n\twith ESMTP id VY8YMrXkC4BR; Wed, 6 Sep 2017 10:33:11 -0400 (EDT)","from localhost (localhost [127.0.0.1])\n\tby mail.savoirfairelinux.com (Postfix) with ESMTP id 064EE9C218B;\n\tWed, 6 Sep 2017 10:33:11 -0400 (EDT)","from mail.savoirfairelinux.com ([127.0.0.1])\n\tby localhost (mail.savoirfairelinux.com [127.0.0.1]) (amavisd-new,\n\tport 10026)\n\twith ESMTP id zHqqm-3ekblX; Wed, 6 Sep 2017 10:33:10 -0400 (EDT)","from localhost (modemcable249.105-163-184.mc.videotron.ca\n\t[184.163.105.249])\n\tby mail.savoirfairelinux.com (Postfix) with ESMTPSA id B25869C209E;\n\tWed, 6 Sep 2017 10:33:10 -0400 (EDT)"],"X-Virus-Scanned":"amavisd-new at mail.savoirfairelinux.com","From":"Vivien Didelot ","To":"Andrew Lunn , netdev ","Cc":"jiri@resnulli.us, nikolay@cumulusnetworks.com,\n\tFlorian Fainelli , Andrew Lunn ","Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","In-Reply-To":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>","Date":"Wed, 06 Sep 2017 10:29:48 -0400","Message-ID":"<87vakvlx2b.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>","MIME-Version":"1.0","Content-Type":"text/plain","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1764170,"web_url":"http://patchwork.ozlabs.org/comment/1764170/","msgid":"","list_archive_url":null,"date":"2017-09-06T14:46:51","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":65471,"url":"http://patchwork.ozlabs.org/api/people/65471/","name":"Matthias May","email":"matthias.may@neratec.com"},"content":"On 06/09/17 02:47, Andrew Lunn wrote:\n>> The third and last issue will be explained in a followup email.\n> \n> Hi DSA hackers\n> \n> So there is the third issue. It affects just DSA, but it possible\n> affects all DSA drivers.\n> \n> This patchset broken broadcast with the Marvell drivers. It could\n> break broadcast on others drivers as well.\n> \n> What i found is that the Marvell chips don't flood broadcast frames\n> between bridged ports. What appears to happen is there is a fdb miss,\n> so it gets forwarded to the CPU port for the host to deal with. The\n> software bridge when floods it out all ports of the bridge.\n> \n> But the set offload_fwd_mark patch changes this. The software bridge\n> now assumes the hardware has already flooded broadcast out all ports\n> of the switch as needed. So it does not do any flooding itself. As a\n> result, on Marvell devices, broadcast packets don't get flooded at\n> all.\n> \n> The issue can be fixed. I just need to add an mdb entry for the\n> broadcast address to each port of the bridge in the switch, and the\n> CPU port. But i don't know at what level to do this.\n> \n> Should this be done at the DSA level, or at the driver level? Do any\n> chips do broadcast flooding in hardware already? Hence they currently\n> see broadcast duplication? If i add a broadcast mdb at the DSA level,\n> and the chip is already hard wired to flooding broadcast, is it going\n> to double flood?\n> \n> \tAndrew\n> \n\nHi Andrew\nWe are using the 88E6321.\nIn our setup we are using openvswitch and not a bridge, however the problem you describe seems to be the same.\n\nWe had to configure the switch to flood unknown multicast (Egress Floods = 0x3, bits 3:2, offset 0x4 in port control)\nand\nunset FloodBC (FloodBC = 0x0, bit 12, offset 0x5 in global 2) which defines if a broadcast should be considered as\nmulticast for the above config.\n\nRegarding the looping problem:\nSince OVS isn't aware of the fdb of the switch, we configure the ports representing the switch ports (in ovs) as\n\"protected\" which prevents looping them back between (even when flooding) see [1].\nI'm not sure if the bridge has a similar feature.\n\nBR\nMatthias\n\n[1]http://openvswitch.org/support/dist-docs/ovs-vswitchd.conf.db.5.txt ctrl-f: \"protected: boolean\"","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnRR31czLz9sRV\n\tfor ;\n\tThu, 7 Sep 2017 00:53:19 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S932673AbdIFOxR convert rfc822-to-8bit (ORCPT\n\t);\n\tWed, 6 Sep 2017 10:53:17 -0400","from mail.neratec.com ([46.140.151.2]:2720 \"EHLO mail.neratec.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S932586AbdIFOxO (ORCPT );\n\tWed, 6 Sep 2017 10:53:14 -0400","from localhost (localhost [127.0.0.1])\n\tby mail.neratec.com (Postfix) with ESMTP id D04A6CE0052;\n\tWed, 6 Sep 2017 16:46:51 +0200 (CEST)","from mail.neratec.com ([127.0.0.1])\n\tby localhost (mail.neratec.com [127.0.0.1]) (amavisd-new, port 10032)\n\twith ESMTP id 4LtaBCiR69Fj; Wed, 6 Sep 2017 16:46:51 +0200 (CEST)","from localhost (localhost [127.0.0.1])\n\tby mail.neratec.com (Postfix) with ESMTP id AA31CCE0297;\n\tWed, 6 Sep 2017 16:46:51 +0200 (CEST)","from mail.neratec.com ([127.0.0.1])\n\tby localhost (mail.neratec.com [127.0.0.1]) (amavisd-new, port 10026)\n\twith ESMTP id GMp8RQrNAZUb; Wed, 6 Sep 2017 16:46:51 +0200 (CEST)","from [192.168.11.50] (unknown [192.168.11.254])\n\tby mail.neratec.com (Postfix) with ESMTPSA id 8202ECE0052;\n\tWed, 6 Sep 2017 16:46:51 +0200 (CEST)"],"X-Greylist":"delayed 381 seconds by postgrey-1.27 at vger.kernel.org;\n\tWed, 06 Sep 2017 10:53:14 EDT","X-Virus-Scanned":"amavisd-new at neratec.com","Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","To":"Andrew Lunn , netdev ,\n\tFlorian Fainelli ,\n\tVivien Didelot ,\n\tWoojung.Huh@microchip.com, jbe@pengutronix.de,\n\tsean.wang@mediatek.com, john@phrozen.org","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>\n\t<20170906004703.GB27385@lunn.ch>","From":"Matthias May ","Message-ID":"","Date":"Wed, 6 Sep 2017 16:46:51 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170906004703.GB27385@lunn.ch>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-GB","Content-Transfer-Encoding":"8BIT","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1764186,"web_url":"http://patchwork.ozlabs.org/comment/1764186/","msgid":"<20170906151640.GC15315@lunn.ch>","list_archive_url":null,"date":"2017-09-06T15:16:40","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"On Wed, Sep 06, 2017 at 04:46:51PM +0200, Matthias May wrote:\n> \n> Hi Andrew\n> We are using the 88E6321.\n> In our setup we are using openvswitch and not a bridge, however the problem you describe seems to be the same.\n> \n> We had to configure the switch to flood unknown multicast (Egress Floods = 0x3, bits 3:2, offset 0x4 in port control)\n> and\n> unset FloodBC (FloodBC = 0x0, bit 12, offset 0x5 in global 2) which defines if a broadcast should be considered as\n> multicast for the above config.\n\nHi Matthias\n\nI might look at this.\n\nBut architecturally it seems better to add an mdb entry for the\nbroadcast address. I hope that work across all switches, where as what\nyou suggests only works for Marvell devices.\n\n Andrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnRy92YBhz9t2R\n\tfor ;\n\tThu, 7 Sep 2017 01:16:49 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S932801AbdIFPQr (ORCPT );\n\tWed, 6 Sep 2017 11:16:47 -0400","from vps0.lunn.ch ([178.209.37.122]:58760 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S932657AbdIFPQq (ORCPT );\n\tWed, 6 Sep 2017 11:16:46 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dpc4G-0004Ui-Pd; Wed, 06 Sep 2017 17:16:40 +0200"],"Date":"Wed, 6 Sep 2017 17:16:40 +0200","From":"Andrew Lunn ","To":"Matthias May ","Cc":"netdev , Florian Fainelli ,\n\tVivien Didelot ,\n\tWoojung.Huh@microchip.com, jbe@pengutronix.de,\n\tsean.wang@mediatek.com, john@phrozen.org","Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","Message-ID":"<20170906151640.GC15315@lunn.ch>","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>\n\t<20170906004703.GB27385@lunn.ch>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1764195,"web_url":"http://patchwork.ozlabs.org/comment/1764195/","msgid":"<20170906082755.58ff6c8f@xeon-e3>","list_archive_url":null,"date":"2017-09-06T15:27:55","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":21389,"url":"http://patchwork.ozlabs.org/api/people/21389/","name":"Stephen Hemminger","email":"stephen@networkplumber.org"},"content":"On Wed, 6 Sep 2017 02:47:03 +0200\nAndrew Lunn wrote:\n\n> > The third and last issue will be explained in a followup email. \n> \n> Hi DSA hackers\n> \n> So there is the third issue. It affects just DSA, but it possible\n> affects all DSA drivers.\n> \n> This patchset broken broadcast with the Marvell drivers. It could\n> break broadcast on others drivers as well.\n> \n> What i found is that the Marvell chips don't flood broadcast frames\n> between bridged ports. What appears to happen is there is a fdb miss,\n> so it gets forwarded to the CPU port for the host to deal with. The\n> software bridge when floods it out all ports of the bridge.\n> \n\nThat sounds like a good feature. There environments where you want\nto disable broadcast between certain ports. It lets the bridge get\nat the traffic for firewall filtering.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=networkplumber-org.20150623.gappssmtp.com\n\theader.i=@networkplumber-org.20150623.gappssmtp.com\n\theader.b=\"cbFvp9S7\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnSCC1cNHz9s03\n\tfor ;\n\tThu, 7 Sep 2017 01:28:07 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S932935AbdIFP2F (ORCPT );\n\tWed, 6 Sep 2017 11:28:05 -0400","from mail-pf0-f180.google.com ([209.85.192.180]:34621 \"EHLO\n\tmail-pf0-f180.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S932263AbdIFP2D (ORCPT\n\t); Wed, 6 Sep 2017 11:28:03 -0400","by mail-pf0-f180.google.com with SMTP id m1so13325684pfk.1\n\tfor ; Wed, 06 Sep 2017 08:28:03 -0700 (PDT)","from xeon-e3 (76-14-207-240.or.wavecable.com. [76.14.207.240])\n\tby smtp.gmail.com with ESMTPSA id\n\tu8sm109108pgq.52.2017.09.06.08.28.02\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tWed, 06 Sep 2017 08:28:02 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=networkplumber-org.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:in-reply-to:references\n\t:mime-version:content-transfer-encoding;\n\tbh=CrSPZCkWrLpHjktox2b67tX778OV66f5pMQn9p+hhLY=;\n\tb=cbFvp9S7g+rFqDjEi3Si5y+j1jKYhdjEMJsQMTurQZA+IFPSZoZezp98Pz9fExh4q1\n\tu2MxnoUmNgRbewfJs0t8jfe4DM1u9q2pe0HgMdJ4LevoknJkz7eQYOd1ABMS2brJG8kt\n\t73EDOPIPG+CDyYIcPRlWK5mYbOUZrIPo6GaoVu8wxTVGlRBwiC1kUXxs7ySbxG6KaEZ2\n\t/AfHjazWbj/W096SNyG+yLfDVz+Ecvael8bTEpqJ6e9J20NXa838lpWaGraH2+wiOrE/\n\tW7RmyLe9kqzWbZFkODTevGLEDAFHSYFJbHLBoyzdMK0mQZK6V7GLu3Pfpcnj91tpNtls\n\tcwFA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to\n\t:references:mime-version:content-transfer-encoding;\n\tbh=CrSPZCkWrLpHjktox2b67tX778OV66f5pMQn9p+hhLY=;\n\tb=Fy8b+7arkc61UrxojuZI2Jk53iPZw7WDDmbH2wJXI6Z51aC3GK34fUGjVmHcNchobE\n\tTExD1EV57l9/QDuwyefpKZb/myGaTnBqGuQDNpKJF+qeMBZV46x3UTsz01SNc7d1piox\n\tTB7MqKRxMA3ZAJxuPRmTgBousF4zlPo47LXRABFo16Z8jutlR4gTUpV2vXHVbpwEkwl+\n\tFQ0hhUj3ta7n9JyrnmR1pRGGfjxrD/ZMKnHZ7spsqgz9i4YugFXQ990rF1u965tOntsN\n\tk8/J73dp6SybzlGpBF5bUDqCnO4PKayPXyy0SMAus4Wek2ik+HsPYxoKS1TziWpDWZhw\n\tJ5Tw==","X-Gm-Message-State":"AHPjjUjlIpkDBIZxEhH2JzUk7xxwJtD0N5OnR/ThXH6xCgai6z122Dcp\n\tPEH+EUwYud1uHG6k","X-Google-Smtp-Source":"ADKCNb4u4wJ5PJ01ixKfAPtwiFVD4gKbvgY+o7pOhmpc4Rr7qI+YEibh6niVaFqBpzaCVbnzm3VTFg==","X-Received":"by 10.98.133.10 with SMTP id u10mr7569107pfd.72.1504711682793;\n\tWed, 06 Sep 2017 08:28:02 -0700 (PDT)","Date":"Wed, 6 Sep 2017 08:27:55 -0700","From":"Stephen Hemminger ","To":"Andrew Lunn ","Cc":"netdev , Florian Fainelli ,\n\tVivien Didelot ,\n\tWoojung.Huh@microchip.com, jbe@pengutronix.de,\n\tsean.wang@mediatek.com, john@phrozen.org","Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","Message-ID":"<20170906082755.58ff6c8f@xeon-e3>","In-Reply-To":"<20170906004703.GB27385@lunn.ch>","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>\n\t<20170906004703.GB27385@lunn.ch>","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1764197,"web_url":"http://patchwork.ozlabs.org/comment/1764197/","msgid":"<874lsfg87t.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>","list_archive_url":null,"date":"2017-09-06T15:25:26","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":15889,"url":"http://patchwork.ozlabs.org/api/people/15889/","name":"Vivien Didelot","email":"vivien.didelot@savoirfairelinux.com"},"content":"Hi Andrew, Nikolay,\n\nAndrew Lunn writes:\n\n> Then starts the work passing down to the hardware that the host has\n> joined/left a group. The existing switchdev mdb object cannot be used,\n> since the semantics are different. The existing\n> SWITCHDEV_OBJ_ID_PORT_MDB is used to indicate a specific multicast\n> group should be forwarded out that port of the switch. However here we\n> require the exact opposite. We want multicast frames for the group\n> received on the port to the forwarded to the host. Hence add a new\n> object SWITCHDEV_OBJ_ID_HOST_MDB, a multicast database entry to\n> forward to the host. This new object is then propagated through the\n> DSA layers. No DSA driver changes should be needed, this should just\n> work...\n\nI'm not sure if you already explained that, if so, sorry in advance.\n\nI don't understand why SWITCHDEV_OBJ_ID_PORT_MDB cannot be used. Isn't\nsetting the obj->orig_dev to the bridge device itself enough to\ndistinguish br0 from a switch port?\n\nThis way, the only change necessary in net/dsa/slave.c is something\nlike (abbreviated):\n\n static int dsa_slave_port_obj_add(struct net_device *dev,\n const struct switchdev_obj *obj,\n struct switchdev_trans *trans)\n {\n struct dsa_slave_priv *p = netdev_priv(dev);\n struct dsa_port *port = p->dp;\n\n /* Is the target port the bridge device itself? */\n if (obj->orig_dev == port->br)\n port = port->cpu_dp;\n\n return dsa_port_mdb_add(port, obj, trans);\n }\n\nThe main problem is that we will soon want support for multiple CPU\nports. This means that each DSA slave will have its dedicated CPU port,\ninstead of having only one for the whole switch tree.\n\nSo adding the MDB entry to all CPU ports as you did in a patch 5/8 in\ndsa_switch_host_mdb_*() is not correct because you can have CPU port\nsw0p0 being a member of br0 and CPU port sw0p10 being a member of br1.\n\nSo is it correct to simply notify SWITCHDEV_OBJ_ID_PORT_MDB with\norig_dev = br->dev so that its members get recursively notified?\n\nEven if SWITCHDEV_OBJ_ID_HOST_MDB is necessary, we need to handle it the\nway I described, otherwise we don't have a correct mapping between a\nslave port and its CPU port that we need to configure.\n\n\nThanks,\n\n Vivien","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnSD53jKwz9s03\n\tfor ;\n\tThu, 7 Sep 2017 01:28:53 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S932984AbdIFP2v (ORCPT );\n\tWed, 6 Sep 2017 11:28:51 -0400","from mail.savoirfairelinux.com ([208.88.110.44]:34636 \"EHLO\n\tmail.savoirfairelinux.com\" rhost-flags-OK-OK-OK-OK) by\n\tvger.kernel.org with ESMTP id S932263AbdIFP2u (ORCPT\n\t); Wed, 6 Sep 2017 11:28:50 -0400","from localhost (localhost [127.0.0.1])\n\tby mail.savoirfairelinux.com (Postfix) with ESMTP id BB1699C1A3A;\n\tWed, 6 Sep 2017 11:28:49 -0400 (EDT)","from mail.savoirfairelinux.com ([127.0.0.1])\n\tby localhost (mail.savoirfairelinux.com [127.0.0.1]) (amavisd-new,\n\tport 10032)\n\twith ESMTP id lQagaD8iAIQE; Wed, 6 Sep 2017 11:28:49 -0400 (EDT)","from localhost (localhost [127.0.0.1])\n\tby mail.savoirfairelinux.com (Postfix) with ESMTP id 4B7469C209E;\n\tWed, 6 Sep 2017 11:28:49 -0400 (EDT)","from mail.savoirfairelinux.com ([127.0.0.1])\n\tby localhost (mail.savoirfairelinux.com [127.0.0.1]) (amavisd-new,\n\tport 10026)\n\twith ESMTP id TYT0fY66OcJo; Wed, 6 Sep 2017 11:28:49 -0400 (EDT)","from localhost (modemcable249.105-163-184.mc.videotron.ca\n\t[184.163.105.249])\n\tby mail.savoirfairelinux.com (Postfix) with ESMTPSA id 13A049C1A3A;\n\tWed, 6 Sep 2017 11:28:49 -0400 (EDT)"],"X-Virus-Scanned":"amavisd-new at mail.savoirfairelinux.com","From":"Vivien Didelot ","To":"Andrew Lunn , netdev ","Cc":"jiri@resnulli.us, nikolay@cumulusnetworks.com,\n\tFlorian Fainelli , Andrew Lunn ","Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","In-Reply-To":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>","Date":"Wed, 06 Sep 2017 11:25:26 -0400","Message-ID":"<874lsfg87t.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>","MIME-Version":"1.0","Content-Type":"text/plain","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1764214,"web_url":"http://patchwork.ozlabs.org/comment/1764214/","msgid":"<9235D6609DB808459E95D78E17F2E43D40B190F2@CHN-SV-EXMX02.mchp-main.com>","list_archive_url":null,"date":"2017-09-06T15:49:26","subject":"RE: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":66705,"url":"http://patchwork.ozlabs.org/api/people/66705/","name":"","email":"Woojung.Huh@microchip.com"},"content":"Andrew,\n\n> What i found is that the Marvell chips don't flood broadcast frames\n> between bridged ports. What appears to happen is there is a fdb miss,\n> so it gets forwarded to the CPU port for the host to deal with. The\n> software bridge when floods it out all ports of the bridge.\nIs this IGMP snooping enabled mode in Marvell chip?","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnSh704xZz9sNV\n\tfor ;\n\tThu, 7 Sep 2017 01:49:43 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755006AbdIFPtk convert rfc822-to-8bit (ORCPT\n\t);\n\tWed, 6 Sep 2017 11:49:40 -0400","from esa6.microchip.iphmx.com ([216.71.154.253]:40143 \"EHLO\n\tesa6.microchip.iphmx.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1755000AbdIFPtk (ORCPT\n\t); Wed, 6 Sep 2017 11:49:40 -0400","from exsmtp01.microchip.com (HELO email.microchip.com)\n\t([198.175.253.37])\n\tby esa6.microchip.iphmx.com with ESMTP/TLS/AES128-SHA;\n\t06 Sep 2017 08:49:27 -0700","from CHN-SV-EXMX02.mchp-main.com ([fe80::7dfe:3761:863e:3963]) by\n\tCHN-SV-EXCH01.mchp-main.com ([fe80::9840:ffdf:ec5:1335%29]) with\n\tmapi id 14.03.0352.000; Wed, 6 Sep 2017 08:49:27 -0700"],"X-IronPort-AV":"E=Sophos;i=\"5.41,484,1498546800\"; d=\"scan'208\";a=\"4239672\"","From":"","To":", , ,\n\t, ,\n\t, ","Subject":"RE: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","Thread-Topic":"[PATCH v2 rfc 0/8] IGMP snooping for local traffic","Thread-Index":"AQHTJqA5POqd6jq51UO5FQfDT0+L46Kne2eAgACFPdA=","Date":"Wed, 6 Sep 2017 15:49:26 +0000","Message-ID":"<9235D6609DB808459E95D78E17F2E43D40B190F2@CHN-SV-EXMX02.mchp-main.com>","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>\n\t<20170906004703.GB27385@lunn.ch>","In-Reply-To":"<20170906004703.GB27385@lunn.ch>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[10.10.76.4]","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"8BIT","MIME-Version":"1.0","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1764217,"web_url":"http://patchwork.ozlabs.org/comment/1764217/","msgid":"","list_archive_url":null,"date":"2017-09-06T15:54:33","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":23500,"url":"http://patchwork.ozlabs.org/api/people/23500/","name":"Roopa Prabhu","email":"roopa@cumulusnetworks.com"},"content":"On Tue, Sep 5, 2017 at 5:47 PM, Andrew Lunn wrote:\n>> The third and last issue will be explained in a followup email.\n>\n> Hi DSA hackers\n>\n> So there is the third issue. It affects just DSA, but it possible\n> affects all DSA drivers.\n>\n> This patchset broken broadcast with the Marvell drivers. It could\n> break broadcast on others drivers as well.\n>\n> What i found is that the Marvell chips don't flood broadcast frames\n> between bridged ports. What appears to happen is there is a fdb miss,\n> so it gets forwarded to the CPU port for the host to deal with. The\n> software bridge when floods it out all ports of the bridge.\n>\n> But the set offload_fwd_mark patch changes this. The software bridge\n> now assumes the hardware has already flooded broadcast out all ports\n> of the switch as needed. So it does not do any flooding itself. As a\n> result, on Marvell devices, broadcast packets don't get flooded at\n> all.\n>\n> The issue can be fixed. I just need to add an mdb entry for the\n> broadcast address to each port of the bridge in the switch, and the\n> CPU port. But i don't know at what level to do this.\n>\n> Should this be done at the DSA level, or at the driver level? Do any\n> chips do broadcast flooding in hardware already? Hence they currently\n> see broadcast duplication? If i add a broadcast mdb at the DSA level,\n> and the chip is already hard wired to flooding broadcast, is it going\n> to double flood?\n>\n\nOn the switch asics we work with, the driver has information if the packet was\nforwarded in hardware. This is per packet reason code telling why the\nCPU is seeing the packet.\nThe driver can use this information to reset skb->offload_fwd_mark to\nallow software forward.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=cumulusnetworks.com\n\theader.i=@cumulusnetworks.com header.b=\"SFej77Zo\"; \n\tdkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnSnp0YbJz9sNV\n\tfor ;\n\tThu, 7 Sep 2017 01:54:38 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755144AbdIFPyg (ORCPT );\n\tWed, 6 Sep 2017 11:54:36 -0400","from mail-ua0-f174.google.com ([209.85.217.174]:34577 \"EHLO\n\tmail-ua0-f174.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1753682AbdIFPyf (ORCPT\n\t); Wed, 6 Sep 2017 11:54:35 -0400","by mail-ua0-f174.google.com with SMTP id s15so14513502uag.1\n\tfor ; Wed, 06 Sep 2017 08:54:34 -0700 (PDT)","by 10.176.73.66 with HTTP; Wed, 6 Sep 2017 08:54:33 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=cumulusnetworks.com; s=google;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=1fEPgnpDMIgPmqHWJ30z/45iDrCmwHCFSfOluj5RNqg=;\n\tb=SFej77ZosJo0STVT/0x2RKcfdJIuMDx9PYPfl5aD3zjSCkDFxuu2bFQQV5SB7VWnur\n\twIk23JiuFF5BK0GFPZ5HMD4AZOb81TnIXi9YozCSzB15iqo/NghPAm/gYmVoPuWB0ijC\n\tpqeh4Y0cawxghjmiDgIbEdQh8kr6j2WaC3wqA=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=1fEPgnpDMIgPmqHWJ30z/45iDrCmwHCFSfOluj5RNqg=;\n\tb=gJ/cTkXts9vBl/FCQ6YoliytRQL28hAOnEUvHW2Uk1aIdx6bZ96NCkyx6U2ynbrvmU\n\trSpdHv8jjKggLTS+jWgUTRMH7Mn48JDvmfa5i1C5XEv2eMrK2HU8jByCHZ5h7Yl7v+vL\n\tTFndg+Btd+bHFI25MrXTgzTrRNXZlCf0T+q3V6v6YkEQOzco0g0KW89TRNsa2MCk7Yuf\n\tRJabIH6qZfQ8ViWIZKFPe7QUkkOBAPPfU/Iv2v+xnSLeDH8C68aCUGiXoXum8+oEntiT\n\tPyrDDH1pMuHVCp796mz2lt6hKJpCy9N7vCIaF0+T8Nc/nkjHbQ42gh2BHlp96lmqlHur\n\tlTLA==","X-Gm-Message-State":"AHPjjUj5KJDf4sOmpNVLqgAI1xBbjf+bX+6my0fPhQXyXrBBFEJffoAL\n\tGqkyfvCSLw1FXpETxAeVHHcIjLYeGWq0","X-Google-Smtp-Source":"ADKCNb4spcGsDREeYjGo7lk9rF2Dph3hmDLLE+36k1T8BNXfaC6sOkTSMBORfPACnxGMGjQtIzEUUHTlNKfwqxxlG1k=","X-Received":"by 10.176.64.162 with SMTP id i31mr1840726uad.60.1504713274136; \n\tWed, 06 Sep 2017 08:54:34 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170906004703.GB27385@lunn.ch>","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>\n\t<20170906004703.GB27385@lunn.ch>","From":"Roopa Prabhu ","Date":"Wed, 6 Sep 2017 08:54:33 -0700","Message-ID":"","Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","To":"Andrew Lunn ","Cc":"netdev , Florian Fainelli ,\n\tVivien Didelot ,\n\tWoojung.Huh@microchip.com, jbe@pengutronix.de,\n\tsean.wang@mediatek.com, john@phrozen.org","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1764224,"web_url":"http://patchwork.ozlabs.org/comment/1764224/","msgid":"<9ECEF4E4-A39B-4578-8BDC-7842D20F3C81@gmail.com>","list_archive_url":null,"date":"2017-09-06T16:06:23","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":2800,"url":"http://patchwork.ozlabs.org/api/people/2800/","name":"Florian Fainelli","email":"f.fainelli@gmail.com"},"content":"On September 6, 2017 8:54:33 AM PDT, Roopa Prabhu wrote:\n>On Tue, Sep 5, 2017 at 5:47 PM, Andrew Lunn wrote:\n>>> The third and last issue will be explained in a followup email.\n>>\n>> Hi DSA hackers\n>>\n>> So there is the third issue. It affects just DSA, but it possible\n>> affects all DSA drivers.\n>>\n>> This patchset broken broadcast with the Marvell drivers. It could\n>> break broadcast on others drivers as well.\n>>\n>> What i found is that the Marvell chips don't flood broadcast frames\n>> between bridged ports. What appears to happen is there is a fdb miss,\n>> so it gets forwarded to the CPU port for the host to deal with. The\n>> software bridge when floods it out all ports of the bridge.\n>>\n>> But the set offload_fwd_mark patch changes this. The software bridge\n>> now assumes the hardware has already flooded broadcast out all ports\n>> of the switch as needed. So it does not do any flooding itself. As a\n>> result, on Marvell devices, broadcast packets don't get flooded at\n>> all.\n>>\n>> The issue can be fixed. I just need to add an mdb entry for the\n>> broadcast address to each port of the bridge in the switch, and the\n>> CPU port. But i don't know at what level to do this.\n>>\n>> Should this be done at the DSA level, or at the driver level? Do any\n>> chips do broadcast flooding in hardware already? Hence they currently\n>> see broadcast duplication? If i add a broadcast mdb at the DSA level,\n>> and the chip is already hard wired to flooding broadcast, is it going\n>> to double flood?\n>>\n>\n>On the switch asics we work with, the driver has information if the\n>packet was\n>forwarded in hardware. This is per packet reason code telling why the\n>CPU is seeing the packet.\n>The driver can use this information to reset skb->offload_fwd_mark to\n>allow software forward.\n\nI am not positive this is universally available across different switch vendors. In Broadcom tag (net/dsa/tag_brcm.c) the reason code definitely tells you that but it also largely depends on whether you have configured SW managed forwarding or not and that translates in having either the HW do all the address learning itself or having SW do it which is less desirable since you end-up with a possibility huge FDB of 4k entries to manage in SW.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"grHxoDCC\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnT3Z34qlz9sRV\n\tfor ;\n\tThu, 7 Sep 2017 02:06:34 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S932762AbdIFQGc (ORCPT );\n\tWed, 6 Sep 2017 12:06:32 -0400","from mail-oi0-f43.google.com ([209.85.218.43]:32824 \"EHLO\n\tmail-oi0-f43.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S932136AbdIFQGa (ORCPT\n\t); Wed, 6 Sep 2017 12:06:30 -0400","by mail-oi0-f43.google.com with SMTP id r20so15301889oie.0\n\tfor ; Wed, 06 Sep 2017 09:06:30 -0700 (PDT)","from ?IPv6:2001:470:d:73f:815a:9e66:852a:ad00?\n\t([2001:470:d:73f:815a:9e66:852a:ad00])\n\tby smtp.gmail.com with ESMTPSA id\n\tq83sm226257oif.4.2017.09.06.09.06.26\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tWed, 06 Sep 2017 09:06:27 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=date:user-agent:in-reply-to:references:mime-version\n\t:content-transfer-encoding:subject:to:cc:from:message-id;\n\tbh=Mn5sCKAHsXeSnkOs/175vnFoHAW1WBQ9AM/1Sjjd4N0=;\n\tb=grHxoDCCIM+RkdRyHf8PFwRSjI86q1X2cb4STlip/OiBxtbdELo8LAtPA2fwoUebrh\n\tPSXb/KPIb2vOyMPLAlwmyVTrHhS8ZHV8/m5XDsq+hV6C5VK2PFvlU08pOjLgYPmeTJBE\n\th4rn+pggGNJm+VMAWnchiPyEOBcCgaXDCz95IDE48Bk7a0FcrvaoVDgxZfrxgXAmNXqS\n\tbhC2c5TBER/o64AT8iAQtnukpR78M9I36TtaQA1MaWVyjrDdGjhRZf6TysiHTT/aKYzN\n\th3eYEMvn7idcnec/er/4cH/CmqWGWJJM8AXKpjlS4QeBkGOZH8WsmWHTdIA5kKkl3mYZ\n\twR7Q==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:user-agent:in-reply-to:references\n\t:mime-version:content-transfer-encoding:subject:to:cc:from\n\t:message-id;\n\tbh=Mn5sCKAHsXeSnkOs/175vnFoHAW1WBQ9AM/1Sjjd4N0=;\n\tb=iZQ5b15XpB6RWvTFOjCULOSmUtqLrMi+x9QHdm6yEedDu9jwknQG9oPJmrCefHXyXn\n\t3/5B5kkJ/kMIN/1NWIvSzU1Sc5VuGm/Vzr00YxUKZ6r4gdmIXwnXslZWG2xZbqWm5I+y\n\t3obFTvGwp5d17m69ZNgglmOazvf2vqRa/Mcum7WP5J00rpl/u3sV6sn+pgtX/dbxYRBp\n\tvUW1CJkajDQlDWfhB3cfC6fdyakQcbiwjqHI645TlD4R1yRj9fn8oOZbne7sNZ+2BhAx\n\ticnF2ed4AU2JfMzziRdadOF897gt6OUEDaaAsMexMAm4TQwaMwfHQlrnTTY9KfN13kAb\n\t9CuA==","X-Gm-Message-State":"AHPjjUhnKCk2NyKFePs2bYxc9wfHXOkXD/hrdvh/bx20v7RsHGyvIRxX\n\t9pZKjEeGAtnuNQ==","X-Google-Smtp-Source":"ADKCNb4kIyrBlCm3WNxHN268uLt3gj2PV3rulSj2DWDFyUMZk6KSEZH/IHY2EDTV3ZIAP1t47L/4gQ==","X-Received":"by 10.202.79.206 with SMTP id d197mr3272216oib.192.1504713990124;\n\tWed, 06 Sep 2017 09:06:30 -0700 (PDT)","Date":"Wed, 06 Sep 2017 09:06:23 -0700","User-Agent":"K-9 Mail for Android","In-Reply-To":"","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>\n\t<20170906004703.GB27385@lunn.ch>\n\t","MIME-Version":"1.0","Content-Type":"text/plain;\n charset=utf-8","Content-Transfer-Encoding":"quoted-printable","Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","To":"Roopa Prabhu , Andrew Lunn ","CC":"netdev ,\n\tVivien Didelot ,\n\tWoojung.Huh@microchip.com, jbe@pengutronix.de,\n\tsean.wang@mediatek.com, john@phrozen.org","From":"Florian Fainelli ","Message-ID":"<9ECEF4E4-A39B-4578-8BDC-7842D20F3C81@gmail.com>","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1764255,"web_url":"http://patchwork.ozlabs.org/comment/1764255/","msgid":"<20170906164217.GE15315@lunn.ch>","list_archive_url":null,"date":"2017-09-06T16:42:17","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"> >On the switch asics we work with, the driver has information if the\n> >packet was\n> >forwarded in hardware. This is per packet reason code telling why the\n> >CPU is seeing the packet.\n> >The driver can use this information to reset skb->offload_fwd_mark to\n> >allow software forward.\n\n> I am not positive this is universally available across different\n> switch vendors.\n\nIt is not universally available. We cannot rely on it being available\nwith switches supported by DSA.\n\nWe have a few choices:\n\n1) We assume anything the switch forwards to the CPU has also been\n sent out whatever ports of the switch it needs to. Set\n offload_fwd_mark.\n\n2) We assume anything the switch forwards to the CPU has not gone\n anywhere else, and the bridge needs to send it out whatever ports\n it thinks. Don't set offload_fwd_mark.\n\n3) We define some rules about what packets the switch should handle,\n and then do some deep packet inspection to decide if\n offload_fwd_mark should be set or not.\n\nI don't see 3) being possible. We are dealing with a fixed silicon\ndata path, not something which is fully programmable.\n\nSo it is down to 1) or 2). I've been assuming 1), but maybe we need to\ndiscuss that as well.\n\n\tAndrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnTs06b3zz9sRV\n\tfor ;\n\tThu, 7 Sep 2017 02:42:28 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755510AbdIFQmZ (ORCPT );\n\tWed, 6 Sep 2017 12:42:25 -0400","from vps0.lunn.ch ([178.209.37.122]:58870 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1754272AbdIFQmW (ORCPT );\n\tWed, 6 Sep 2017 12:42:22 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dpdP7-00058R-W0; Wed, 06 Sep 2017 18:42:17 +0200"],"Date":"Wed, 6 Sep 2017 18:42:17 +0200","From":"Andrew Lunn ","To":"Florian Fainelli ","Cc":"Roopa Prabhu ,\n\tnetdev ,\n\tVivien Didelot ,\n\tWoojung.Huh@microchip.com, jbe@pengutronix.de,\n\tsean.wang@mediatek.com, john@phrozen.org","Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","Message-ID":"<20170906164217.GE15315@lunn.ch>","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>\n\t<20170906004703.GB27385@lunn.ch>\n\t\n\t<9ECEF4E4-A39B-4578-8BDC-7842D20F3C81@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<9ECEF4E4-A39B-4578-8BDC-7842D20F3C81@gmail.com>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1764264,"web_url":"http://patchwork.ozlabs.org/comment/1764264/","msgid":"<20170906170120.GF15315@lunn.ch>","list_archive_url":null,"date":"2017-09-06T17:01:20","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"On Wed, Sep 06, 2017 at 11:25:26AM -0400, Vivien Didelot wrote:\n> Hi Andrew, Nikolay,\n> \n> Andrew Lunn writes:\n> \n> > Then starts the work passing down to the hardware that the host has\n> > joined/left a group. The existing switchdev mdb object cannot be used,\n> > since the semantics are different. The existing\n> > SWITCHDEV_OBJ_ID_PORT_MDB is used to indicate a specific multicast\n> > group should be forwarded out that port of the switch. However here we\n> > require the exact opposite. We want multicast frames for the group\n> > received on the port to the forwarded to the host. Hence add a new\n> > object SWITCHDEV_OBJ_ID_HOST_MDB, a multicast database entry to\n> > forward to the host. This new object is then propagated through the\n> > DSA layers. No DSA driver changes should be needed, this should just\n> > work...\n> \n> I'm not sure if you already explained that, if so, sorry in advance.\n> \n> I don't understand why SWITCHDEV_OBJ_ID_PORT_MDB cannot be used. Isn't\n> setting the obj->orig_dev to the bridge device itself enough to\n> distinguish br0 from a switch port?\n\nHi Vivien\n\nI did consider this. But conceptually, it seems wrong.\nSWITCHDEV_OBJ_ID_PORT_MDB has always been about egress. I don't like\nadding a special case for ingress. Adding a new switchdev object\navoids this special case.\n\n> static int dsa_slave_port_obj_add(struct net_device *dev,\n> const struct switchdev_obj *obj,\n> struct switchdev_trans *trans)\n> {\n> struct dsa_slave_priv *p = netdev_priv(dev);\n> struct dsa_port *port = p->dp;\n> \n> /* Is the target port the bridge device itself? */\n> if (obj->orig_dev == port->br)\n> port = port->cpu_dp;\n> \n> return dsa_port_mdb_add(port, obj, trans);\n> }\n> \n> The main problem is that we will soon want support for multiple CPU\n> ports.\n\nWe keep saying that, but it never actually happens. We should solve\nmultiple CPU problems when we actually add support for multiple CPUs.\nProbably at that point, we need to push SWITCHDEV_OBJ_ID_PORT_HOST_MDB\nright down to a port, so that port can setup what needs setting up so\nits frames goes to its CPU port.\n\n> So adding the MDB entry to all CPU ports as you did in a patch 5/8 in\n> dsa_switch_host_mdb_*() is not correct because you can have CPU port\n> sw0p0 being a member of br0 and CPU port sw0p10 being a member of br1.\n\nBe careful, you are making assumptions about mapping cpu ports to\nbridges. That is not been defined yet.\n\n\t Andrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnVGt5zRbz9t2d\n\tfor ;\n\tThu, 7 Sep 2017 03:01:26 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754669AbdIFRBX (ORCPT );\n\tWed, 6 Sep 2017 13:01:23 -0400","from vps0.lunn.ch ([178.209.37.122]:58883 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1753829AbdIFRBW (ORCPT );\n\tWed, 6 Sep 2017 13:01:22 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dpdhY-0005Jg-16; Wed, 06 Sep 2017 19:01:20 +0200"],"Date":"Wed, 6 Sep 2017 19:01:20 +0200","From":"Andrew Lunn ","To":"Vivien Didelot ","Cc":"netdev , jiri@resnulli.us,\n\tnikolay@cumulusnetworks.com, Florian Fainelli ","Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","Message-ID":"<20170906170120.GF15315@lunn.ch>","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>\n\t<874lsfg87t.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<874lsfg87t.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1764307,"web_url":"http://patchwork.ozlabs.org/comment/1764307/","msgid":"<87o9qnel4p.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>","list_archive_url":null,"date":"2017-09-06T18:29:26","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":15889,"url":"http://patchwork.ozlabs.org/api/people/15889/","name":"Vivien Didelot","email":"vivien.didelot@savoirfairelinux.com"},"content":"Hi Andrew,\n\nAndrew Lunn writes:\n\n>> I don't understand why SWITCHDEV_OBJ_ID_PORT_MDB cannot be used. Isn't\n>> setting the obj->orig_dev to the bridge device itself enough to\n>> distinguish br0 from a switch port?\n>\n> I did consider this. But conceptually, it seems wrong.\n> SWITCHDEV_OBJ_ID_PORT_MDB has always been about egress. I don't like\n> adding a special case for ingress. Adding a new switchdev object\n> avoids this special case.\n\nSWITCHDEV_OBJ_ID_PORT_MDB means manipulating an MDB entry on a port.\nWhen one want to add an MDB entry to br0, SWITCHDEV_OBJ_ID_PORT_MDB is\nused. If the device is br->dev, the lower devices (bridged ports) get\nrecursively notified and switchdev users can program themselves\naccordingly. In the case of DSA, a slave port will program its\nassociated CPU port (port->cpu_dp) if orig_dev is a bridge.\n\nThis seems totally correct to me. I don't see any reason for adding and\nmaintaining a new switchdev object. What do switchdev guys think?\n\n>> The main problem is that we will soon want support for multiple CPU\n>> ports.\n>\n> We keep saying that, but it never actually happens. We should solve\n> multiple CPU problems when we actually add support for multiple CPUs.\n> Probably at that point, we need to push SWITCHDEV_OBJ_ID_PORT_HOST_MDB\n> right down to a port, so that port can setup what needs setting up so\n> its frames goes to its CPU port.\n\nThis is not correct. I am currently making this easier, i.e. the\ndsa_master patchset I sent before net-next closed.\n\nI do understand your point however and even if this multi-CPU feature\ntakes time to arrive, we can always find a proper design which makes it\neasy. Assuming that each port has its dedicated CPU port is the correct\nconcept to follow.\n\n>> So adding the MDB entry to all CPU ports as you did in a patch 5/8 in\n>> dsa_switch_host_mdb_*() is not correct because you can have CPU port\n>> sw0p0 being a member of br0 and CPU port sw0p10 being a member of br1.\n>\n> Be careful, you are making assumptions about mapping cpu ports to\n> bridges. That is not been defined yet.\n\nI am not making any assumptions, but you did because you assume that all\nCPU ports will be part of the same bridge.\n\nWe need to handle things at the DSA core level the following way:\n\nIf one programs the bridge device itself, a switchdev object is\nnotified, and each DSA slave devices member of the bridge will call the\ncorrect dsa_port_* function (agnostic to the port type) with its cpu_dp.\n\nThis covers cleanly all cases. You also don't need any new DSA notifier.\nYou only need your 6/8 patch. To acheive that, there is two ways:\n\n1) either we keep SWITCHDEV_OBJ_ID_PORT_MDB for the bridge device itself\nand the slave devices are notified accordingly with a correct orig_dev:\n\n static int dsa_slave_port_obj_add(struct net_device *dev,\n const struct switchdev_obj *obj,\n struct switchdev_trans *trans)\n {\n struct dsa_slave_priv *p = netdev_priv(dev);\n struct dsa_port *port = p->dp;\n \n /* Program the CPU port if the target is the bridge itself */\n if (obj->orig_dev == port->br)\n port = port->cpu_dp;\n \n switch (obj->id) {\n case SWITCHDEV_OBJ_ID_PORT_MDB:\n return dsa_port_mdb_add(port, obj, trans);\n ...\n }\n }\n\n2) or you introduce a switchdev object which, by definition, targets the\nCPU ports of our bridge members:\n\n static int dsa_slave_port_obj_add(struct net_device *dev,\n const struct switchdev_obj *obj,\n struct switchdev_trans *trans)\n {\n struct dsa_slave_priv *p = netdev_priv(dev);\n struct dsa_port *port = p->dp;\n\n switch (obj->id) {\n case SWITCHDEV_OBJ_ID_PORT_HOST_MDB:\n port = port->cpu_dp;\n /* fall through... */\n case SWITCHDEV_OBJ_ID_PORT_MDB:\n return dsa_port_mdb_add(port, obj, trans);\n ...\n }\n }\n\nYou basically just need that and your 6/8 patch for the DSA part.\n\n\nThanks,\n\n Vivien","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnXJW1Zdpz9t2W\n\tfor ;\n\tThu, 7 Sep 2017 04:32:59 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752247AbdIFScy (ORCPT );\n\tWed, 6 Sep 2017 14:32:54 -0400","from mail.savoirfairelinux.com ([208.88.110.44]:46932 \"EHLO\n\tmail.savoirfairelinux.com\" rhost-flags-OK-OK-OK-OK) by\n\tvger.kernel.org with ESMTP id S1752220AbdIFScv (ORCPT\n\t); Wed, 6 Sep 2017 14:32:51 -0400","from localhost (localhost [127.0.0.1])\n\tby mail.savoirfairelinux.com (Postfix) with ESMTP id 8A78D9C2377;\n\tWed, 6 Sep 2017 14:32:50 -0400 (EDT)","from mail.savoirfairelinux.com ([127.0.0.1])\n\tby localhost (mail.savoirfairelinux.com [127.0.0.1]) (amavisd-new,\n\tport 10032)\n\twith ESMTP id VWgAFTziJgSL; Wed, 6 Sep 2017 14:32:49 -0400 (EDT)","from localhost (localhost [127.0.0.1])\n\tby mail.savoirfairelinux.com (Postfix) with ESMTP id B77269C23FE;\n\tWed, 6 Sep 2017 14:32:49 -0400 (EDT)","from mail.savoirfairelinux.com ([127.0.0.1])\n\tby localhost (mail.savoirfairelinux.com [127.0.0.1]) (amavisd-new,\n\tport 10026)\n\twith ESMTP id z7EoV-wmj8xq; Wed, 6 Sep 2017 14:32:49 -0400 (EDT)","from localhost (modemcable249.105-163-184.mc.videotron.ca\n\t[184.163.105.249])\n\tby mail.savoirfairelinux.com (Postfix) with ESMTPSA id 808B09C2377;\n\tWed, 6 Sep 2017 14:32:49 -0400 (EDT)"],"X-Virus-Scanned":"amavisd-new at mail.savoirfairelinux.com","From":"Vivien Didelot ","To":"Andrew Lunn ","Cc":"netdev , jiri@resnulli.us,\n\tnikolay@cumulusnetworks.com, Florian Fainelli ","Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","In-Reply-To":"<20170906170120.GF15315@lunn.ch>","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>\n\t<874lsfg87t.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170906170120.GF15315@lunn.ch>","Date":"Wed, 06 Sep 2017 14:29:26 -0400","Message-ID":"<87o9qnel4p.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>","MIME-Version":"1.0","Content-Type":"text/plain","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1764332,"web_url":"http://patchwork.ozlabs.org/comment/1764332/","msgid":"<44233399-2cb9-35af-2b93-b0024aac8dc4@gmail.com>","list_archive_url":null,"date":"2017-09-06T19:54:28","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":2800,"url":"http://patchwork.ozlabs.org/api/people/2800/","name":"Florian Fainelli","email":"f.fainelli@gmail.com"},"content":"On 09/06/2017 09:42 AM, Andrew Lunn wrote:\n>>> On the switch asics we work with, the driver has information if the\n>>> packet was\n>>> forwarded in hardware. This is per packet reason code telling why the\n>>> CPU is seeing the packet.\n>>> The driver can use this information to reset skb->offload_fwd_mark to\n>>> allow software forward.\n> \n>> I am not positive this is universally available across different\n>> switch vendors.\n> \n> It is not universally available. We cannot rely on it being available\n> with switches supported by DSA.\n> \n> We have a few choices:\n> \n> 1) We assume anything the switch forwards to the CPU has also been\n> sent out whatever ports of the switch it needs to. Set\n> offload_fwd_mark.\n> \n> 2) We assume anything the switch forwards to the CPU has not gone\n> anywhere else, and the bridge needs to send it out whatever ports\n> it thinks. Don't set offload_fwd_mark.\n> \n> 3) We define some rules about what packets the switch should handle,\n> and then do some deep packet inspection to decide if\n> offload_fwd_mark should be set or not.\n> \n> I don't see 3) being possible. We are dealing with a fixed silicon\n> data path, not something which is fully programmable.\n> \n> So it is down to 1) or 2). I've been assuming 1), but maybe we need to\n> discuss that as well.\n\nAt the very least we should probably move the skb->offload_fwd_mark\nsetting down into the individual taggers since they should be in a\nbetter position to set it or not based on the switch device they are\ndriving, this should address, on a per-switch basis whether 2) or 3)\napplies to a given switch.\n\nThat being said, I have a feeling that the Marvell switches behave a\ntiny bit differently than others in that they do not flood broadcast by\ndefault in a given L2 domain.\n\nOn b53/bcm_sf2 there is the ability to disable the reception of\nbroadcast frames on the management/CPU port, and while there is the\nability to configure which ports should be flooded in case of\nunicast/multicast lookup failures, I don't see anything for Broadcast,\nso I am assuming this will get forwarded by default. Will test with your\npatch set later on time permitting.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"YaJ49N49\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnZ6q67tsz9sCZ\n\tfor ;\n\tThu, 7 Sep 2017 05:54:43 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752454AbdIFTyl (ORCPT );\n\tWed, 6 Sep 2017 15:54:41 -0400","from mail-wm0-f42.google.com ([74.125.82.42]:37049 \"EHLO\n\tmail-wm0-f42.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752255AbdIFTyk (ORCPT\n\t); Wed, 6 Sep 2017 15:54:40 -0400","by mail-wm0-f42.google.com with SMTP id u26so34874089wma.0\n\tfor ; Wed, 06 Sep 2017 12:54:40 -0700 (PDT)","from [10.112.156.244] ([192.19.255.250])\n\tby smtp.googlemail.com with ESMTPSA id\n\t14sm649232wrw.21.2017.09.06.12.54.31\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tWed, 06 Sep 2017 12:54:38 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=2Rj38pIfxhuOpbjb+WLBHxKWqTLKynUJ2fBnhOavpfA=;\n\tb=YaJ49N49Q8Carc9ikreAq/I9ggv3llHdECCAn3oM8Zkr3BtxcxZG6W6tFt47I1Z5L5\n\ti3Di9wdbMAjNx43FCYGdmVxW1TDq/eLdBc/o2FAUDcIRLw+vn+nPiJLR6VDpImUhmayE\n\tTtF9RMIFzaCS2NVCbqPEjapdmQYOIVTW+3AoX4ynJGSJjPIL0Tcsja1RGmdJ6cfQE+xR\n\tbjNjXsuCQXSqnboUj5Xvbx3nXjUWTBQ884SdX4vz9VWrZFj26w4jwC5rr49LWMgtqELw\n\tSwbIWXRwuT1JtEPpaFjbNKK1ylcJxBdtriu+SkbF/EMSyyqMrOI1btjE1E0lQb3rn6ue\n\tMKjg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=2Rj38pIfxhuOpbjb+WLBHxKWqTLKynUJ2fBnhOavpfA=;\n\tb=PyTnguNky0pCnOWefS2K1GXQpoDliUaIqba+N+SF4GH38jWb0Yuv0EuosyQseVrx8Y\n\tA8yii6815lM8LeUsqK1fDkcQ6OhHuQt9nOfEczbzlbhfM/1sjrNHmOC51olhSPtwN5bO\n\tKahvBoNQ57gfE3A8l7A1hALbDMIxZ77L1HvDBgc/+qsQ5ORFnjBS2S2NYifSVcqVeUYF\n\t7o8NHA7s6ZBZGoXyY6PDJpxj6LVnri8+cUle9B1sI+iD0Tskr/5y3QhmCSji4Dpj3e7j\n\tW0+nWKjRoLSY9Z9uNkPWD8ksrkMQLji46PIxBlltBTgT1bSP090lIPskBi91rn4baWcW\n\t1PIQ==","X-Gm-Message-State":"AHPjjUh/6cPW8imHZO8S5StUEhDk4B8itMylbSKgbvbqXwe2gerf25KI\n\tHsJ1vdSE9HwAMGKYZl4=","X-Google-Smtp-Source":"ADKCNb7rcmK//LmHIxy1du0IgLmBpiLfbVImJh8FB9iNXqzThfRPOvWHhhNmEQ8nr59tGJm/u7pwvA==","X-Received":"by 10.28.74.134 with SMTP id n6mr554921wmi.61.1504727679469;\n\tWed, 06 Sep 2017 12:54:39 -0700 (PDT)","Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","To":"Andrew Lunn ","Cc":"Roopa Prabhu ,\n\tnetdev ,\n\tVivien Didelot ,\n\tWoojung.Huh@microchip.com, jbe@pengutronix.de,\n\tsean.wang@mediatek.com, john@phrozen.org","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>\n\t<20170906004703.GB27385@lunn.ch>\n\t\n\t<9ECEF4E4-A39B-4578-8BDC-7842D20F3C81@gmail.com>\n\t<20170906164217.GE15315@lunn.ch>","From":"Florian Fainelli ","Message-ID":"<44233399-2cb9-35af-2b93-b0024aac8dc4@gmail.com>","Date":"Wed, 6 Sep 2017 12:54:28 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170906164217.GE15315@lunn.ch>","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"}},{"id":1764439,"web_url":"http://patchwork.ozlabs.org/comment/1764439/","msgid":"<9235D6609DB808459E95D78E17F2E43D40B19584@CHN-SV-EXMX02.mchp-main.com>","list_archive_url":null,"date":"2017-09-06T23:44:47","subject":"RE: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":66705,"url":"http://patchwork.ozlabs.org/api/people/66705/","name":"","email":"Woojung.Huh@microchip.com"},"content":"> That being said, I have a feeling that the Marvell switches behave a\r\n> tiny bit differently than others in that they do not flood broadcast by\r\n> default in a given L2 domain.\r\nFlorian,\r\n\r\nBecause some DSA switches from Marvell & Microchip can do IGMP snooping, \r\ncan we propose switch layer another flag what to do when HW support it?\r\n\r\n- Woojung","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xngFG0384z9s9Y\n\tfor ;\n\tThu, 7 Sep 2017 09:45:38 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752274AbdIFXpf (ORCPT );\n\tWed, 6 Sep 2017 19:45:35 -0400","from esa5.microchip.iphmx.com ([216.71.150.166]:13558 \"EHLO\n\tesa5.microchip.iphmx.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751471AbdIFXpe (ORCPT\n\t); Wed, 6 Sep 2017 19:45:34 -0400","from smtpout.microchip.com (HELO email.microchip.com)\n\t([198.175.253.82])\n\tby esa5.microchip.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-SHA;\n\t06 Sep 2017 16:44:49 -0700","from CHN-SV-EXMX02.mchp-main.com ([fe80::7dfe:3761:863e:3963]) by\n\tCHN-SV-EXCH04.mchp-main.com ([fe80::6150:8a42:4945:9b1b%16]) with\n\tmapi id 14.03.0352.000; Wed, 6 Sep 2017 16:44:48 -0700"],"X-IronPort-AV":"E=Sophos;i=\"5.42,355,1500966000\"; d=\"scan'208\";a=\"4481838\"","From":"","To":", ","CC":", ,\n\t, ,\n\t, ","Subject":"RE: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","Thread-Topic":"[PATCH v2 rfc 0/8] IGMP snooping for local traffic","Thread-Index":"AQHTJqA5POqd6jq51UO5FQfDT0+L46Kne2eAgAD9joCAAANOgIAACgiAgAA1sgD//8nf0A==","Date":"Wed, 6 Sep 2017 23:44:47 +0000","Message-ID":"<9235D6609DB808459E95D78E17F2E43D40B19584@CHN-SV-EXMX02.mchp-main.com>","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>\n\t<20170906004703.GB27385@lunn.ch>\n\t\n\t<9ECEF4E4-A39B-4578-8BDC-7842D20F3C81@gmail.com>\n\t<20170906164217.GE15315@lunn.ch>\n\t<44233399-2cb9-35af-2b93-b0024aac8dc4@gmail.com>","In-Reply-To":"<44233399-2cb9-35af-2b93-b0024aac8dc4@gmail.com>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[10.10.76.4]","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","MIME-Version":"1.0","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1764444,"web_url":"http://patchwork.ozlabs.org/comment/1764444/","msgid":"<20170907004308.GA30089@lunn.ch>","list_archive_url":null,"date":"2017-09-07T00:43:08","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"On Wed, Sep 06, 2017 at 11:44:47PM +0000, Woojung.Huh@microchip.com wrote:\n> > That being said, I have a feeling that the Marvell switches behave a\n> > tiny bit differently than others in that they do not flood broadcast by\n> > default in a given L2 domain.\n> Florian,\n> \n> Because some DSA switches from Marvell & Microchip can do IGMP snooping, \n> can we propose switch layer another flag what to do when HW support it?\n \nHi Woojung\n\nI expect all the current DSA devices should be able to do IGMP\nsnooping, with some modifications.\n\nTwo things are required:\n\n1) The .port_mdb_prepare, .port_mdb_add and .port_mdb_del ops, so that\nmdb entries can be added. As you said, only Marvell and Microchip\nsupport these, but i expect the other switch can do this, it just\nneeds implementing.\n\n2) The switch needs to identify and forward IGMP packets to the host,\neven when they would normally be blocked.\n\nAnd for the implementation, i don't think it actually matters. For\nswitches which don't implement the port_mdb operations, IGMP packets\nwill get forwarded to the software bridge. It will attempt to put in\nan mdb, but the request will come back with EOPNOTSUPP. The switch\nshould continue to flood multicast out all ports. No harm done.\n\n Andrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnhWm70sRz9t2W\n\tfor ;\n\tThu, 7 Sep 2017 10:43:16 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751985AbdIGAnP (ORCPT );\n\tWed, 6 Sep 2017 20:43:15 -0400","from vps0.lunn.ch ([178.209.37.122]:59142 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751369AbdIGAnN (ORCPT );\n\tWed, 6 Sep 2017 20:43:13 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dpkuS-00086z-N4; Thu, 07 Sep 2017 02:43:08 +0200"],"Date":"Thu, 7 Sep 2017 02:43:08 +0200","From":"Andrew Lunn ","To":"Woojung.Huh@microchip.com","Cc":"f.fainelli@gmail.com, roopa@cumulusnetworks.com,\n\tnetdev@vger.kernel.org, vivien.didelot@savoirfairelinux.com,\n\tjbe@pengutronix.de, sean.wang@mediatek.com, john@phrozen.org","Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","Message-ID":"<20170907004308.GA30089@lunn.ch>","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>\n\t<20170906004703.GB27385@lunn.ch>\n\t\n\t<9ECEF4E4-A39B-4578-8BDC-7842D20F3C81@gmail.com>\n\t<20170906164217.GE15315@lunn.ch>\n\t<44233399-2cb9-35af-2b93-b0024aac8dc4@gmail.com>\n\t<9235D6609DB808459E95D78E17F2E43D40B19584@CHN-SV-EXMX02.mchp-main.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<9235D6609DB808459E95D78E17F2E43D40B19584@CHN-SV-EXMX02.mchp-main.com>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1764445,"web_url":"http://patchwork.ozlabs.org/comment/1764445/","msgid":"<20170907004753.GB30089@lunn.ch>","list_archive_url":null,"date":"2017-09-07T00:47:53","subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"> At the very least we should probably move the skb->offload_fwd_mark\n> setting down into the individual taggers since they should be in a\n> better position to set it or not based on the switch device they are\n> driving, this should address, on a per-switch basis whether 2) or 3)\n> applies to a given switch.\n\nYes, that could be done.\n\n> That being said, I have a feeling that the Marvell switches behave a\n> tiny bit differently than others in that they do not flood broadcast by\n> default in a given L2 domain.\n\nIt seems like the switch can be configured to flood broadcast. Just at\nthe moment, it is not.\n\n> On b53/bcm_sf2 there is the ability to disable the reception of\n> broadcast frames on the management/CPU port, and while there is the\n> ability to configure which ports should be flooded in case of\n> unicast/multicast lookup failures, I don't see anything for Broadcast,\n> so I am assuming this will get forwarded by default. Will test with your\n> patch set later on time permitting.\n\nPlease let me know the results of the tests.\n\nIf Marvell is being different, it also means that all other switches\ntoday are duplicating broadcasts. We should fix that. In fact, i think\nwe need to fix this first, before these patches for IGMP snooping on\nbr0 goes in.\n\n Andrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnhdB6wKVz9sCZ\n\tfor ;\n\tThu, 7 Sep 2017 10:47:58 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753081AbdIGAr4 (ORCPT );\n\tWed, 6 Sep 2017 20:47:56 -0400","from vps0.lunn.ch ([178.209.37.122]:59151 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752856AbdIGAr4 (ORCPT );\n\tWed, 6 Sep 2017 20:47:56 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dpkz3-00089s-B8; Thu, 07 Sep 2017 02:47:53 +0200"],"Date":"Thu, 7 Sep 2017 02:47:53 +0200","From":"Andrew Lunn ","To":"Florian Fainelli ","Cc":"Roopa Prabhu ,\n\tnetdev ,\n\tVivien Didelot ,\n\tWoojung.Huh@microchip.com, jbe@pengutronix.de,\n\tsean.wang@mediatek.com, john@phrozen.org","Subject":"Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic","Message-ID":"<20170907004753.GB30089@lunn.ch>","References":"<1504654510-31004-1-git-send-email-andrew@lunn.ch>\n\t<20170906004703.GB27385@lunn.ch>\n\t\n\t<9ECEF4E4-A39B-4578-8BDC-7842D20F3C81@gmail.com>\n\t<20170906164217.GE15315@lunn.ch>\n\t<44233399-2cb9-35af-2b93-b0024aac8dc4@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<44233399-2cb9-35af-2b93-b0024aac8dc4@gmail.com>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]