linux-kernel - Re: [PATCH net-next 10/11] net: marvell: prestera: add storm control (rate limiter) implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 10 Jun 2021 12:31:40 +0300
From:   Nikolay Aleksandrov <nikolay@...dia.com>
To:     Ido Schimmel <idosch@...sch.org>,
        Oleksandr Mazur <oleksandr.mazur@...ision.eu>
Cc:     jiri@...dia.com, davem@...emloft.net, kuba@...nel.org,
        Vadym Kochan <vkochan@...vell.com>,
        Taras Chornyi <tchornyi@...vell.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, roopa@...dia.com
Subject: Re: [PATCH net-next 10/11] net: marvell: prestera: add storm control
 (rate limiter) implementation

On 09/06/2021 20:59, Ido Schimmel wrote:
> On Wed, Jun 09, 2021 at 06:16:00PM +0300, Oleksandr Mazur wrote:
>> Storm control (BUM) provides a mechanism to limit rate of ingress
>> port traffic (matched by type). Devlink port parameter API is used:
>> driver registers a set of per-port parameters that can be accessed to both
>> get/set per-port per-type rate limit.
>> Add new FW command - RATE_LIMIT_MODE_SET.
> 
> This should be properly modeled in the bridge driver and offloaded to
> capable drivers via switchdev. Modeling it as a driver-specific devlink
> parameter is wrong.
> 

Absolutely agree with Ido, there are many different ways to achieve it through
the bridge (e.g. generic bridge helpers to be used by bpf, directly by tc or new br tc hooks
to name a few). I'd personally be excited to see any of these implemented as they
could open the door for a lot other interesting use cases. Unfortunately I'm currently swamped
with per-vlan multicast support, after that depending on time availability I could look
into this unless someone beats me to it. :)

Cheers,
 Nik