[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Y7vT2IwhmJ5PK6F1@nanopsycho>
Date: Mon, 9 Jan 2023 09:44:08 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Ido Schimmel <idosch@...dia.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
pabeni@...hat.com, edumazet@...gle.com, michael.chan@...adcom.com,
yisen.zhuang@...wei.com, salil.mehta@...wei.com,
jesse.brandeburg@...el.com, anthony.l.nguyen@...el.com,
tariqt@...dia.com, saeedm@...dia.com, leon@...nel.org,
petrm@...dia.com, mailhol.vincent@...adoo.fr,
jacob.e.keller@...el.com, gal@...dia.com
Subject: Re: [patch net-next v2 4/9] devlink: remove reporters_lock
Sun, Jan 08, 2023 at 05:28:50PM CET, idosch@...dia.com wrote:
>On Sat, Jan 07, 2023 at 11:11:45AM +0100, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@...dia.com>
>>
>> Similar to other devlink objects, convert the reporters list to be
>> protected by devlink instance lock. Alongside add unlocked versions
>> of health reporter create functions and remove port-specific destroy
>> function which is no longer needed.
>>
>> Signed-off-by: Jiri Pirko <jiri@...dia.com>
>> ---
>> .../ethernet/mellanox/mlx5/core/en/health.c | 12 ++
>> .../mellanox/mlx5/core/en/reporter_rx.c | 6 +-
>> .../mellanox/mlx5/core/en/reporter_tx.c | 6 +-
>> drivers/net/ethernet/mellanox/mlxsw/core.c | 8 +-
>> drivers/net/netdevsim/health.c | 20 +--
>> include/net/devlink.h | 20 +--
>> net/devlink/core.c | 2 -
>> net/devlink/devl_internal.h | 1 -
>> net/devlink/leftover.c | 131 +++++++-----------
>> 9 files changed, 96 insertions(+), 110 deletions(-)
>
>This is quite difficult to review because there are multiple changes
>squashed into one patch:
>
>1. Addition of locked versions of both device and port health reporter
>while refactoring the code to share code paths.
>
>2. Removal of the reporters mutex.
>
>3. Partial conversion of drivers to use the locked APIs. The conversion
>of mlxsw and netdevsim is trivial because they hold the instance lock
>during probe, but the conversion of mlx5 is less trivial. I would split
>it into a separate patch.
Yeah, I was thinking about splitting this, however since the new lock
needs to be used on locked path with different helpers, it is not easy
to find a good split, was a bit lazy to do that. Anyway, let me think
and try again. Thanks!
Powered by blists - more mailing lists