netdev - Re: [PATCH net-next 00/11] Marvell Prestera driver implementation of devlink functionality.

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, 17 Jun 2021 17:30:07 +0000
From:   Oleksandr Mazur <oleksandr.mazur@...ision.eu>
To:     "jiri@...dia.com" <jiri@...dia.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 00/11] Marvell Prestera driver implementation of
 devlink functionality.

> Prestera Switchdev driver implements a set of devlink-based features,
> that include both debug functionality (traps with trap statistics), as well
> as functional rate limiter that is based on the devlink kernel API (interfaces).

> The core prestera-devlink functionality is implemented in the prestera_devlink.c.

> The patch series also extends the existing devlink kernel API with a list of core
> features:
>  - devlink: add API for both publish/unpublish port parameters.
>  - devlink: add port parameters-specific ops, as current design makes it impossible
>    to register one parameter for multiple ports, and effectively distinguish for
>   what port parameter_op is called.

As we discussed the storm control (BUM) done via devlink port params topic, and agreed that it shouldn't be done using the devlink API itself, there's an open question i'd like to address: the patch series included, for what i think, list of needed and benefitial changes, and those are the following patches:

> Oleksandr Mazur (2):
...
>  net: core: devlink: add port_params_ops for devlink port parameters altering
>  drivers: net: netdevsim: add devlink port params usage
 
> Sudarsana Reddy Kalluru (1):
>  net: core: devlink: add apis to publish/unpublish port params

So, should i create a new patch series that would include all of them?

Because in that case the series itself would lack an actual HW usage of it. The only usage would be limited to the netdevsim driver.