Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760176AbaGRFho (ORCPT ); Fri, 18 Jul 2014 01:37:44 -0400 Received: from devils.ext.ti.com ([198.47.26.153]:34290 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759597AbaGRFhl (ORCPT ); Fri, 18 Jul 2014 01:37:41 -0400 Message-ID: <53C8B29F.5@ti.com> Date: Fri, 18 Jul 2014 11:07:35 +0530 From: Mugunthan V N User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: David Laight , David Miller CC: "netdev@vger.kernel.org" , "linux-api@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [net-next PATCH v2 0/3] Broadcast/Multicast rate limit via Ethtool Coalesce References: <1404890050-4020-1-git-send-email-mugunthanvnm@ti.com> <20140709.164420.157865201153845876.davem@davemloft.net> <53C76990.3000304@ti.com> <063D6719AE5E284EB5DD2968C1650D6D172768B0@AcuExch.aculab.com> In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D172768B0@AcuExch.aculab.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 17 July 2014 06:23 PM, David Laight wrote: >> From: Mugunthan V N >> On Thursday 10 July 2014 05:14 AM, David Miller wrote: >>> From: Mugunthan V N >>> Date: Wed, 9 Jul 2014 12:44:07 +0530 >>> >>>> A system/cpu can be loaded by a hacker with flooding of broadcast or >>>> multicast packets, to prevent this some Ethernet controllers like CPSW >>>> provide a mechanism to limit the broadcast/multicast packet rate via >>>> hardware limiters. This patch series enables this feature via >>>> Ethtool Coalesce. >>> This is pretty bogus if you ask me. >>> >>> What is the difference from accepting a high rate of unicast packets? >>> I say it is no different. >>> >>> Therefore, this feature makes no sense to me at all. >> Any packet storm can cause an endpoint some issues. Typically packet >> storms will cause the system CPU to thrash resulting is very low system >> performance. >> >> Unicast storms only target a single destination end station, it can be >> easily mitigated by the host adding a blocking entry in the LUT for each >> aggressor. >> >> Broadcast and multicast target multiple end stations, or an entire >> network, not only can it cause CPU thrashing, it can result in loss of >> other broadcast and multicast services. The rate limiting feature allow >> the broadcast and or multicast traffic to be dropped if the rates are >> too high. This eliminates the CPU thrashing issue. It also allows the >> system to analyze the aggressors and block them for future transgressions. > Rate limiting multicast traffic will definitely cause the loss of multicast > services. When a system apply the rate limit, the system should expect to miss some of the broadcast/multicast packet depending on the rate limit it applies. > > My experience of broadcast storms is that many of the ethernet switches > (probably especially the cheap ones) end up using a much slower software? > path for broadcasts. In a broadcast storm they start discarding normal > traffic - to point where a single ssh session becomes unusable. > This is true even when isolated from the storm by a 10M hub. > > Broadcast storms are probably mostly caused by network topology issues. > Especially is switches are sending traffic to 'all ports' while resetting > the spanning tree tables. > This is one more example where broadcast/multicast rate limit can be used. Regards Mugunthan V N -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/