netdev - 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]

Message-ID: <AM0P190MB0738E3909FB0EA0031A24F07E4349@AM0P190MB0738.EURP190.PROD.OUTLOOK.COM>
Date:   Fri, 11 Jun 2021 13:19:13 +0000
From:   Oleksandr Mazur <oleksandr.mazur@...ision.eu>
To:     Andrew Lunn <andrew@...n.ch>
CC:     "jiri@...dia.com" <jiri@...dia.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        Vadym Kochan <vkochan@...vell.com>,
        Taras Chornyi <tchornyi@...vell.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Taras Chornyi <taras.chornyi@...ision.eu>,
        Vadym Kochan <vadym.kochan@...ision.eu>,
        Serhiy Pshyk <serhiy.pshyk@...ision.eu>,
        Volodymyr Mytnyk <volodymyr.mytnyk@...ision.eu>
Subject: Re: [PATCH net-next 10/11] net: marvell: prestera: add storm control
 (rate limiter) implementation

>>  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.

> Hi Oleksandr

> Just expanding on the two comments you already received about this.

> We often see people miss that switchdev is about. It is not about
> writing switch drivers. It is about writing network stack
> accelerators. You take a feature of the Linux network stack and you
> accelerate it by offloading it to the hardware. So look around the
> network stack and see how you configure it to perform rate limiting of
> broadcast traffic ingress. Once you have found a suitable mechanism,
> accelerate it via offloading.

> If you find Linux has no way to perform a feature the hardware could
> accelerate, you first need to add a pure software version of that
> feature to the network stack, and then add acceleration support for
> it.


Hello Andrew, Ido, Nikolay,
I appreciate your time and comments provided over this patchset, though i have a few questions to ask, if you don't mind:

1. Does it mean that in order to support storm control in switchdev driver i need to implement software storm control in bridge driver,
and then using the switchdev attributes (notifiers) mechanism offload the configuration itself to the HW?
2. Is there any chance of keeping devlink solution untill the discussed (storm control implemented in the bridge driver) mechanism will be ready/implemented?

Anyway, it relies on the port param API from devlink which is already present in the kernel API.