From: Nikolay Aleksandrov <nikolay@nvidia.com>
To: Ido Schimmel <idosch@idosch.org>,
Oleksandr Mazur <oleksandr.mazur@plvision.eu>
Cc: jiri@nvidia.com, davem@davemloft.net, kuba@kernel.org,
Vadym Kochan <vkochan@marvell.com>,
Taras Chornyi <tchornyi@marvell.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
roopa@nvidia.com
Subject: Re: [PATCH net-next 10/11] net: marvell: prestera: add storm control (rate limiter) implementation
Date: Thu, 10 Jun 2021 12:31:40 +0300 [thread overview]
Message-ID: <b5c527a1-ce54-8679-e0f2-bc18e9351dd0@nvidia.com> (raw)
In-Reply-To: <YMEBcqqY5PopjRKq@shredder>
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
next prev parent reply other threads:[~2021-06-10 9:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-09 15:15 [PATCH net-next 00/11] Marvell Prestera driver implementation of devlink functionality Oleksandr Mazur
2021-06-09 15:15 ` [PATCH net-next 01/11] net: core: devlink: add apis to publish/unpublish port params Oleksandr Mazur
2021-06-09 15:15 ` [PATCH net-next 02/11] net: core: devlink: add dropped stats traps field Oleksandr Mazur
2021-06-09 15:15 ` [PATCH net-next 03/11] net: core: devlink: add port_params_ops for devlink port parameters altering Oleksandr Mazur
2021-06-09 15:15 ` [PATCH net-next 04/11] testing: selftests: net: forwarding: add devlink-required functionality to test (hard) dropped stats field Oleksandr Mazur
2021-06-09 15:15 ` [PATCH net-next 05/11] drivers: net: netdevsim: add devlink trap_drop_counter_get implementation Oleksandr Mazur
2021-06-09 15:15 ` [PATCH net-next 06/11] testing: selftests: drivers: net: netdevsim: devlink: add test case for hard drop statistics Oleksandr Mazur
2021-06-09 15:15 ` [PATCH net-next 07/11] drivers: net: netdevsim: add devlink port params usage Oleksandr Mazur
2021-06-09 15:15 ` [PATCH net-next 08/11] net: marvell: prestera: devlink: add traps/groups implementation Oleksandr Mazur
2021-06-09 15:15 ` [PATCH net-next 09/11] net: marvell: prestera: devlink: add traps with DROP action Oleksandr Mazur
2021-06-09 15:16 ` [PATCH net-next 10/11] net: marvell: prestera: add storm control (rate limiter) implementation Oleksandr Mazur
2021-06-09 17:59 ` Ido Schimmel
2021-06-10 9:31 ` Nikolay Aleksandrov [this message]
2021-06-10 12:41 ` Andrew Lunn
2021-06-11 13:19 ` Oleksandr Mazur
2021-06-11 17:08 ` Andrew Lunn
2021-06-13 7:34 ` Ido Schimmel
2021-06-16 7:15 ` kernel test robot
2021-06-16 7:15 ` kernel test robot
2021-06-09 15:16 ` [PATCH net-next 11/11] documentation: networking: devlink: add prestera switched driver Documentation Oleksandr Mazur
2021-06-17 17:30 ` [PATCH net-next 00/11] Marvell Prestera driver implementation of devlink functionality Oleksandr Mazur
2021-06-17 19:44 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b5c527a1-ce54-8679-e0f2-bc18e9351dd0@nvidia.com \
--to=nikolay@nvidia.com \
--cc=davem@davemloft.net \
--cc=idosch@idosch.org \
--cc=jiri@nvidia.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=oleksandr.mazur@plvision.eu \
--cc=roopa@nvidia.com \
--cc=tchornyi@marvell.com \
--cc=vkochan@marvell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.