[{"id":1772345,"web_url":"http://patchwork.ozlabs.org/comment/1772345/","msgid":"<20170920.180512.587163028605109912.davem@davemloft.net>","list_archive_url":null,"date":"2017-09-21T01:05:12","subject":"Re: [patch net-next 00/16] mlxsw: Multicast flood update","submitter":{"id":15,"url":"http://patchwork.ozlabs.org/api/people/15/","name":"David Miller","email":"davem@davemloft.net"},"content":"From: Jiri Pirko \nDate: Wed, 20 Sep 2017 16:15:00 +0200\n\n> From: Jiri Pirko \n> \n> Nogah says:\n> \n> Currently, there are four erroneous flows in MC flood:\n> 1. When MC is disabled it affects only the flood table for unregistered\n> MC packets, but packets that match an entry in the MDB are unaffected.\n> 2. When MC is disabled, MC packets are being sent to all the ports in the\n> bridge (like BC and link-local MC packets) regardless of the designated\n> flag (BR_MCAST_FLAG).\n> 3. When a port is being deleted from a bridge it might remain in the MDB.\n> 4. When MC is enabled packets are flooded to the mrouter ports only if\n> they don't match any entry in the MDB, when they should always be\n> flooded to them.\n> \n> What these problems have in common is the discrepancy between how the\n> hardware handles MDB and mcast flood, and how the driver does it. Each\n> of these problems needs fixing either in the MDB code, or in mcast flood\n> code, and some in both.\n> \n> Patches 1-6 change the way the MDB is handled in the driver to make the\n> following changes easier.\n> Patches 7-8 fix problem number 1 by removing the MDB from the HW when MC\n> is being disabled and restoring it when it is being enabled.\n> Patches 9-10 fix problem number 2 by offloading the flood table by the\n> appropriate flag.\n> Patch 11 fixes problem number 3 by adding MDB flush to the port removal.\n> Patches 12-14 fix problem number 4 by adding the mrouter ports to every\n> MDB entry in the HW to mimic the wanted behaviour.\n\nLooks good, series applied, thanks!","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 3xyJLh62btz9s0Z\n\tfor ;\n\tThu, 21 Sep 2017 11:05:16 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752191AbdIUBFO (ORCPT );\n\tWed, 20 Sep 2017 21:05:14 -0400","from shards.monkeyblade.net ([184.105.139.130]:45366 \"EHLO\n\tshards.monkeyblade.net\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751769AbdIUBFN (ORCPT\n\t); Wed, 20 Sep 2017 21:05:13 -0400","from localhost (74-93-104-98-Washington.hfc.comcastbusiness.net\n\t[74.93.104.98]) (using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(Client did not present a certificate)\n\t(Authenticated sender: davem-davemloft)\n\tby shards.monkeyblade.net (Postfix) with ESMTPSA id 370721018C096;\n\tWed, 20 Sep 2017 18:05:13 -0700 (PDT)"],"Date":"Wed, 20 Sep 2017 18:05:12 -0700 (PDT)","Message-Id":"<20170920.180512.587163028605109912.davem@davemloft.net>","To":"jiri@resnulli.us","Cc":"netdev@vger.kernel.org, nogahf@mellanox.com, idosch@mellanox.com,\n\tmlxsw@mellanox.com","Subject":"Re: [patch net-next 00/16] mlxsw: Multicast flood update","From":"David Miller ","In-Reply-To":"<20170920141516.1402-1-jiri@resnulli.us>","References":"<20170920141516.1402-1-jiri@resnulli.us>","X-Mailer":"Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)","Mime-Version":"1.0","Content-Type":"Text/Plain; charset=us-ascii","Content-Transfer-Encoding":"7bit","X-Greylist":"Sender succeeded SMTP AUTH, not delayed by\n\tmilter-greylist-4.5.12 (shards.monkeyblade.net\n\t[149.20.54.216]); Wed, 20 Sep 2017 18:05:13 -0700 (PDT)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]