[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51604140-bafe-2fd6-65b1-0a3b732c83bd@ti.com>
Date: Mon, 9 Apr 2018 11:13:55 -0400
From: Murali Karicheri <m-karicheri2@...com>
To: Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>
CC: David Miller <davem@...emloft.net>, <netdev@...r.kernel.org>
Subject: Re: Enable and configure storm prevention in a network device
Andrew,
On 04/06/2018 10:30 AM, Andrew Lunn wrote:
> On Thu, Apr 05, 2018 at 03:35:06PM -0700, Florian Fainelli wrote:
>> On 04/05/2018 01:20 PM, David Miller wrote:
>>> From: Murali Karicheri <m-karicheri2@...com>
>>> Date: Thu, 5 Apr 2018 16:14:49 -0400
>>>
>>>> Is there a standard way to implement and configure storm prevention
>>>> in a Linux network device?
>>>
>>> What kind of "storm", an interrupt storm?
>>>
>>
>> I would assume Murali is referring to L2 broadcast storms which is
>> common in switches. There is not an API for that AFAICT and I am not
>> sure what a proper API would look like.
>
> tc?
>
> The Marvell switches have leaky buckets, which can be used for
> limiting broadcast and multicast packets, as well as traffic shaping
> in general. Storm prevention is just a form of traffic shaping, so if
> we have generic traffic shaping, it can be used for storm prevention.
>
TI's CPSW hardware as well has similar capability to limit broadcast and
multicast packets at the ingress. Isn't it a traffic policing at the Ingress
rather than traffic shaping as the hardware drops the frames at the ingress
if the rate exceeds a limit?
I haven't done any work on TC, but with my limited knowledge of TC, it
seems we might be able to use TC to offload the TC policing to the hardware
through ndo_setup_tc()? Could someone shed some light on how to do this
with tc? Some tc filer command and then some hook in kernel to offload this
to hardware?
Murali
> Andrew
>
--
Murali Karicheri
Linux Kernel, Keystone
Powered by blists - more mailing lists