mbox series

[net-next,v2,0/7] Add devlink-health support for devlink ports

Message ID 1593746858-6548-1-git-send-email-moshe@mellanox.com
Headers show
Series Add devlink-health support for devlink ports | expand

Message

Moshe Shemesh July 3, 2020, 3:27 a.m. UTC
Implement support for devlink health reporters on per-port basis. First
part in the series prepares common functions parts for health reporter
implementation. Second introduces required API to devlink-health and
mlx5e ones demonstrate its usage and effectively implement the feature
for mlx5 driver.
The per-port reporter functionality is achieved by adding a list of
devlink_health_reporters to devlink_port struct in a manner similar to
existing device infrastructure. This is the only major difference and
it makes possible to fully reuse device reporters operations.
The effect will be seen in conjunction with iproute2 additions and
will affect all devlink health commands. User can distinguish between
device and port reporters by looking at a devlink handle. Port reporters
have a port index at the end of the address and such addresses can be
provided as a parameter in every place where devlink-health accepted it.
These can be obtained from devlink port show command.
For example:
$ devlink health show
pci/0000:00:0a.0:
  reporter fw
    state healthy error 0 recover 0 auto_dump true
pci/0000:00:0a.0/1:
  reporter tx
    state healthy error 0 recover 0 grace_period 500 auto_recover true auto_dump true
$ devlink health set pci/0000:00:0a.0/1 reporter tx grace_period 1000 \
auto_recover false auto_dump false
$ devlink health show pci/0000:00:0a.0/1 reporter tx
pci/0000:00:0a.0/1:
  reporter tx
    state healthy error 0 recover 0 grace_period 1000 auto_recover flase auto_dump false

Changes v1 -> v2:
Fixed functions comment to match parameters list.

Vladyslav Tarasiuk (7):
  devlink: Refactor devlink health reporter constructor
  devlink: Rework devlink health reporter destructor
  devlink: Create generic devlink health reporter search function
  devlink: Implement devlink health reporters on per-port basis
  devlink: Add devlink health port reporters API
  net/mlx5e: Move devlink port register and unregister calls
  net/mlx5e: Move devlink-health rx and tx reporters to devlink port

 .../ethernet/mellanox/mlx5/core/en/reporter_rx.c   |   9 +-
 .../ethernet/mellanox/mlx5/core/en/reporter_tx.c   |  13 +-
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c  |  15 +-
 include/net/devlink.h                              |  11 +
 net/core/devlink.c                                 | 244 ++++++++++++++++-----
 5 files changed, 216 insertions(+), 76 deletions(-)

Comments

Jakub Kicinski July 3, 2020, 11:44 p.m. UTC | #1
On Fri,  3 Jul 2020 06:27:31 +0300 Moshe Shemesh wrote:
> Implement support for devlink health reporters on per-port basis. First
> part in the series prepares common functions parts for health reporter
> implementation. Second introduces required API to devlink-health and
> mlx5e ones demonstrate its usage and effectively implement the feature
> for mlx5 driver.
> The per-port reporter functionality is achieved by adding a list of
> devlink_health_reporters to devlink_port struct in a manner similar to
> existing device infrastructure. This is the only major difference and
> it makes possible to fully reuse device reporters operations.
> The effect will be seen in conjunction with iproute2 additions and
> will affect all devlink health commands. User can distinguish between
> device and port reporters by looking at a devlink handle. Port reporters
> have a port index at the end of the address and such addresses can be
> provided as a parameter in every place where devlink-health accepted it.
> These can be obtained from devlink port show command.
> For example:
> $ devlink health show
> pci/0000:00:0a.0:
>   reporter fw
>     state healthy error 0 recover 0 auto_dump true
> pci/0000:00:0a.0/1:
>   reporter tx
>     state healthy error 0 recover 0 grace_period 500 auto_recover true auto_dump true
> $ devlink health set pci/0000:00:0a.0/1 reporter tx grace_period 1000 \
> auto_recover false auto_dump false
> $ devlink health show pci/0000:00:0a.0/1 reporter tx
> pci/0000:00:0a.0/1:
>   reporter tx
>     state healthy error 0 recover 0 grace_period 1000 auto_recover flase auto_dump false

What's the motivation, though?

This patch series achieves nothing that couldn't be previously achieved.

Is there no concern of uAPI breakage with moving the existing health
reporters in patch 7?
Jiri Pirko July 4, 2020, 2:16 p.m. UTC | #2
Sat, Jul 04, 2020 at 01:44:39AM CEST, kuba@kernel.org wrote:
>On Fri,  3 Jul 2020 06:27:31 +0300 Moshe Shemesh wrote:
>> Implement support for devlink health reporters on per-port basis. First
>> part in the series prepares common functions parts for health reporter
>> implementation. Second introduces required API to devlink-health and
>> mlx5e ones demonstrate its usage and effectively implement the feature
>> for mlx5 driver.
>> The per-port reporter functionality is achieved by adding a list of
>> devlink_health_reporters to devlink_port struct in a manner similar to
>> existing device infrastructure. This is the only major difference and
>> it makes possible to fully reuse device reporters operations.
>> The effect will be seen in conjunction with iproute2 additions and
>> will affect all devlink health commands. User can distinguish between
>> device and port reporters by looking at a devlink handle. Port reporters
>> have a port index at the end of the address and such addresses can be
>> provided as a parameter in every place where devlink-health accepted it.
>> These can be obtained from devlink port show command.
>> For example:
>> $ devlink health show
>> pci/0000:00:0a.0:
>>   reporter fw
>>     state healthy error 0 recover 0 auto_dump true
>> pci/0000:00:0a.0/1:
>>   reporter tx
>>     state healthy error 0 recover 0 grace_period 500 auto_recover true auto_dump true
>> $ devlink health set pci/0000:00:0a.0/1 reporter tx grace_period 1000 \
>> auto_recover false auto_dump false
>> $ devlink health show pci/0000:00:0a.0/1 reporter tx
>> pci/0000:00:0a.0/1:
>>   reporter tx
>>     state healthy error 0 recover 0 grace_period 1000 auto_recover flase auto_dump false
>
>What's the motivation, though?
>
>This patch series achieves nothing that couldn't be previously achieved.

Well, not really. If you have 2 ports, you have 2 set's of tx/rx health
reporters. Cannot achieve that w/o per-port health reporters.


>
>Is there no concern of uAPI breakage with moving the existing health
>reporters in patch 7?

No. This is bug by design that we are fixing now. No other way around :/
This is mlx5 only.
Jakub Kicinski July 5, 2020, 4:48 p.m. UTC | #3
On Sat, 4 Jul 2020 16:16:42 +0200 Jiri Pirko wrote:
> Sat, Jul 04, 2020 at 01:44:39AM CEST, kuba@kernel.org wrote:
> >On Fri,  3 Jul 2020 06:27:31 +0300 Moshe Shemesh wrote:  
> >> Implement support for devlink health reporters on per-port basis. First
> >> part in the series prepares common functions parts for health reporter
> >> implementation. Second introduces required API to devlink-health and
> >> mlx5e ones demonstrate its usage and effectively implement the feature
> >> for mlx5 driver.
> >> The per-port reporter functionality is achieved by adding a list of
> >> devlink_health_reporters to devlink_port struct in a manner similar to
> >> existing device infrastructure. This is the only major difference and
> >> it makes possible to fully reuse device reporters operations.
> >> The effect will be seen in conjunction with iproute2 additions and
> >> will affect all devlink health commands. User can distinguish between
> >> device and port reporters by looking at a devlink handle. Port reporters
> >> have a port index at the end of the address and such addresses can be
> >> provided as a parameter in every place where devlink-health accepted it.
> >> These can be obtained from devlink port show command.
> >> For example:
> >> $ devlink health show
> >> pci/0000:00:0a.0:
> >>   reporter fw
> >>     state healthy error 0 recover 0 auto_dump true
> >> pci/0000:00:0a.0/1:
> >>   reporter tx
> >>     state healthy error 0 recover 0 grace_period 500 auto_recover true auto_dump true
> >> $ devlink health set pci/0000:00:0a.0/1 reporter tx grace_period 1000 \
> >> auto_recover false auto_dump false
> >> $ devlink health show pci/0000:00:0a.0/1 reporter tx
> >> pci/0000:00:0a.0/1:
> >>   reporter tx
> >>     state healthy error 0 recover 0 grace_period 1000 auto_recover flase auto_dump false  
> >
> >What's the motivation, though?
> >
> >This patch series achieves nothing that couldn't be previously achieved.  
> 
> Well, not really. If you have 2 ports, you have 2 set's of tx/rx health
> reporters. Cannot achieve that w/o per-port health reporters.

Which mlx5 doesn't. Each port has its own instance of devlink today.

> >Is there no concern of uAPI breakage with moving the existing health
> >reporters in patch 7?  
> 
> No. This is bug by design that we are fixing now. No other way around :/
> This is mlx5 only.

Please repost including in the cover letter a proper an explanation of
why the change is necessary, what benefits it will bring us, what are
next steps, and why it doesn't matter much that the health reporters
move for mlx5.

The cover letter describes code not reasoning, which is IMHO
unacceptable for patches that "change" uAPI.
Moshe Shemesh July 6, 2020, 12:09 p.m. UTC | #4
On 7/5/2020 7:48 PM, Jakub Kicinski wrote:
> On Sat, 4 Jul 2020 16:16:42 +0200 Jiri Pirko wrote:
>> Sat, Jul 04, 2020 at 01:44:39AM CEST, kuba@kernel.org wrote:
>>> On Fri,  3 Jul 2020 06:27:31 +0300 Moshe Shemesh wrote:
>>>> Implement support for devlink health reporters on per-port basis. First
>>>> part in the series prepares common functions parts for health reporter
>>>> implementation. Second introduces required API to devlink-health and
>>>> mlx5e ones demonstrate its usage and effectively implement the feature
>>>> for mlx5 driver.
>>>> The per-port reporter functionality is achieved by adding a list of
>>>> devlink_health_reporters to devlink_port struct in a manner similar to
>>>> existing device infrastructure. This is the only major difference and
>>>> it makes possible to fully reuse device reporters operations.
>>>> The effect will be seen in conjunction with iproute2 additions and
>>>> will affect all devlink health commands. User can distinguish between
>>>> device and port reporters by looking at a devlink handle. Port reporters
>>>> have a port index at the end of the address and such addresses can be
>>>> provided as a parameter in every place where devlink-health accepted it.
>>>> These can be obtained from devlink port show command.
>>>> For example:
>>>> $ devlink health show
>>>> pci/0000:00:0a.0:
>>>>    reporter fw
>>>>      state healthy error 0 recover 0 auto_dump true
>>>> pci/0000:00:0a.0/1:
>>>>    reporter tx
>>>>      state healthy error 0 recover 0 grace_period 500 auto_recover true auto_dump true
>>>> $ devlink health set pci/0000:00:0a.0/1 reporter tx grace_period 1000 \
>>>> auto_recover false auto_dump false
>>>> $ devlink health show pci/0000:00:0a.0/1 reporter tx
>>>> pci/0000:00:0a.0/1:
>>>>    reporter tx
>>>>      state healthy error 0 recover 0 grace_period 1000 auto_recover flase auto_dump false
>>> What's the motivation, though?
>>>
>>> This patch series achieves nothing that couldn't be previously achieved.
>> Well, not really. If you have 2 ports, you have 2 set's of tx/rx health
>> reporters. Cannot achieve that w/o per-port health reporters.
> Which mlx5 doesn't. Each port has its own instance of devlink today.


That's right for mlx5, but in the general case Tx and Rx should be per 
port and not per device.

Better to fix the API before more drivers use it for such reporters.

>>> Is there no concern of uAPI breakage with moving the existing health
>>> reporters in patch 7?
>> No. This is bug by design that we are fixing now. No other way around :/
>> This is mlx5 only.
> Please repost including in the cover letter a proper an explanation of
> why the change is necessary, what benefits it will bring us, what are
> next steps, and why it doesn't matter much that the health reporters
> move for mlx5.
>
> The cover letter describes code not reasoning, which is IMHO
> unacceptable for patches that "change" uAPI.


Sure, will fix and resend.