Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15 |
|
#
c11138f0 |
| 28-Jan-2024 |
Moshe Shemesh <moshe@nvidia.com> |
net/mlx5: Check capability for fw_reset
[ Upstream commit 5e6107b499f3fc4748109e1d87fd9603b34f1e0d ]
Functions which can't access MFRL (Management Firmware Reset Level) register, have no use of fw_
net/mlx5: Check capability for fw_reset
[ Upstream commit 5e6107b499f3fc4748109e1d87fd9603b34f1e0d ]
Functions which can't access MFRL (Management Firmware Reset Level) register, have no use of fw_reset structures or events. Remove fw_reset structures allocation and registration for fw reset events notifications for these functions.
Having the devlink param enable_remote_dev_reset on functions that don't have this capability is misleading as these functions are not allowed to influence the reset flow. Hence, this patch removes this parameter for such functions.
In addition, return not supported on devlink reload action fw_activate for these functions.
Fixes: 38b9f903f22b ("net/mlx5: Handle sync reset request event") Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Aya Levin <ayal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32 |
|
#
a9f168e4 |
| 31-May-2023 |
Moshe Shemesh <moshe@nvidia.com> |
net/mlx5: Check with FW that sync reset completed successfully
Even if the PF driver had no error on his part of the sync reset flow, the firmware can see wider picture as it syncs all the PFs in th
net/mlx5: Check with FW that sync reset completed successfully
Even if the PF driver had no error on his part of the sync reset flow, the firmware can see wider picture as it syncs all the PFs in the flow. So add at end of sync reset flow check with firmware by reading MFRL register and initialization segment that the flow had no issue from firmware point of view too.
Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
Revision tags: v6.1.31, v6.1.30, v6.1.29, v6.1.28 |
|
#
e71383fb |
| 03-May-2023 |
Shay Drory <shayd@nvidia.com> |
net/mlx5: Light probe local SFs
In case user wants to configure the SFs, for example: to use only vdpa functionality, he needs to fully probe a SF, configure what he wants, and afterward reload the
net/mlx5: Light probe local SFs
In case user wants to configure the SFs, for example: to use only vdpa functionality, he needs to fully probe a SF, configure what he wants, and afterward reload the SF.
In order to save the time of the reload, local SFs will probe without any auxiliary sub-device, so that the SFs can be configured prior to its full probe.
The defaults of the enable_* devlink params of these SFs are set to false.
Usage example: Create SF: $ devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 11 $ devlink port function set pci/0000:08:00.0/32768 \ hw_addr 00:00:00:00:00:11 state active
Enable ETH auxiliary device: $ devlink dev param set auxiliary/mlx5_core.sf.1 \ name enable_eth value true cmode driverinit
Now, in order to fully probe the SF, use devlink reload: $ devlink dev reload auxiliary/mlx5_core.sf.1
At this point the user have SF devlink instance with auxiliary device for the Ethernet functionality only.
Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
3f908403 |
| 17-May-2023 |
Shay Drory <shayd@nvidia.com> |
net/mlx5: Move esw multiport devlink param to eswitch code
Move the param registration and handling code into the eswitch code as they are related to each other. No point in having the devlink param
net/mlx5: Move esw multiport devlink param to eswitch code
Move the param registration and handling code into the eswitch code as they are related to each other. No point in having the devlink param registration done in separate file.
Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
216ba9f4 |
| 26-May-2023 |
Jiri Pirko <jiri@nvidia.com> |
devlink: move port_del() to devlink_port_ops
Move port_del() from devlink_ops into newly introduced devlink_port_ops.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba
devlink: move port_del() to devlink_port_ops
Move port_del() from devlink_ops into newly introduced devlink_port_ops.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
216aa67f |
| 26-May-2023 |
Jiri Pirko <jiri@nvidia.com> |
devlink: move port_fn_state_get/set() to devlink_port_ops
Move port_fn_state_get/set() from devlink_ops into newly introduced devlink_port_ops.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-of
devlink: move port_fn_state_get/set() to devlink_port_ops
Move port_fn_state_get/set() from devlink_ops into newly introduced devlink_port_ops.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
4a490d71 |
| 26-May-2023 |
Jiri Pirko <jiri@nvidia.com> |
devlink: move port_fn_migratable_get/set() to devlink_port_ops
Move port_fn_migratable_get/set() from devlink_ops into newly introduced devlink_port_ops.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
devlink: move port_fn_migratable_get/set() to devlink_port_ops
Move port_fn_migratable_get/set() from devlink_ops into newly introduced devlink_port_ops.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
933c1327 |
| 26-May-2023 |
Jiri Pirko <jiri@nvidia.com> |
devlink: move port_fn_roce_get/set() to devlink_port_ops
Move port_fn_roce_get/set() from devlink_ops into newly introduced devlink_port_ops.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-
devlink: move port_fn_roce_get/set() to devlink_port_ops
Move port_fn_roce_get/set() from devlink_ops into newly introduced devlink_port_ops.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
71c93e37 |
| 26-May-2023 |
Jiri Pirko <jiri@nvidia.com> |
devlink: move port_fn_hw_addr_get/set() to devlink_port_ops
Move port_fn_hw_addr_get/set() from devlink_ops into newly introduced devlink_port_ops.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Acked
devlink: move port_fn_hw_addr_get/set() to devlink_port_ops
Move port_fn_hw_addr_get/set() from devlink_ops into newly introduced devlink_port_ops.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
0279b545 |
| 02-May-2023 |
Roi Dayan <roid@nvidia.com> |
net/mlx5: devlink, Only show PF related devlink warning when needed
Limit the PF related warning to show if device is actually a PF.
Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Maor Dic
net/mlx5: devlink, Only show PF related devlink warning when needed
Limit the PF related warning to show if device is actually a PF.
Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
Revision tags: v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21 |
|
#
c511822f |
| 22-Mar-2023 |
Roi Dayan <roid@nvidia.com> |
net/mlx5: Remove redundant esw multiport validate function
The function didn't validate the value and doesn't require value validation as it will always be valid true or false values.
Signed-off-by
net/mlx5: Remove redundant esw multiport validate function
The function didn't validate the value and doesn't require value validation as it will always be valid true or false values.
Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
dfad9975 |
| 01-Apr-2023 |
Moshe Shemesh <moshe@nvidia.com> |
net/mlx5: Use recovery timeout on sync reset flow
Use the same timeout for sync reset flow and health recovery flow, since the former involves driver's recovery from firmware reset, which is similar
net/mlx5: Use recovery timeout on sync reset flow
Use the same timeout for sync reset flow and health recovery flow, since the former involves driver's recovery from firmware reset, which is similar to health recovery. Otherwise, in some cases, such as a firmware upgrade on the DPU, the firmware pre-init bit may not be ready within current timeout and the driver will abort loading back after reset.
Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Fixes: 37ca95e62ee2 ("net/mlx5: Increase FW pre-init timeout for health recovery") Reviewed-by: Maher Sanalla <msanalla@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
Revision tags: v6.1.20 |
|
#
1bffcea4 |
| 14-Mar-2023 |
Gal Pressman <gal@nvidia.com> |
net/mlx5e: Add devlink hairpin queues parameters
We refer to a TC NIC rule that involves forwarding as "hairpin". Hairpin queues are mlx5 hardware specific implementation for hardware forwarding of
net/mlx5e: Add devlink hairpin queues parameters
We refer to a TC NIC rule that involves forwarding as "hairpin". Hairpin queues are mlx5 hardware specific implementation for hardware forwarding of such packets.
Per the discussion in [1], move the hairpin queues control (number and size) from debugfs to devlink.
Expose two devlink params: - hairpin_num_queues: control the number of hairpin queues - hairpin_queue_size: control the size (in packets) of the hairpin queues
[1] https://lore.kernel.org/all/20230111194608.7f15b9a1@kernel.org/
Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/r/20230314054234.267365-12-saeed@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
ceefcfb8 |
| 14-Mar-2023 |
Jiri Pirko <jiri@nvidia.com> |
net/mlx5: Add comment to mlx5_devlink_params_register()
Add comment to mlx5_devlink_params_register() functions so it is clear that only driver init params should be registered here.
Signed-off-by:
net/mlx5: Add comment to mlx5_devlink_params_register()
Add comment to mlx5_devlink_params_register() functions so it is clear that only driver init params should be registered here.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/r/20230314054234.267365-4-saeed@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
Revision tags: v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9 |
|
#
72ed5d56 |
| 26-Jan-2023 |
Jiri Pirko <jiri@nvidia.com> |
net/mlx5: Suspend auxiliary devices only in case of PCI device suspend
The original behavior introduced by commit c6acd629eec7 ("net/mlx5e: Add support for devlink-port in non-representors mode") co
net/mlx5: Suspend auxiliary devices only in case of PCI device suspend
The original behavior introduced by commit c6acd629eec7 ("net/mlx5e: Add support for devlink-port in non-representors mode") correctly re-instantiated uplink devlink port and related netdevice during devlink reload. However with migration to auxiliary devices, this behaviour changed.
Restore the original behaviour and tear down auxiliary devices completely during devlink reload.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
Revision tags: v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11 |
|
#
8ce81fc0 |
| 01-Dec-2022 |
Roi Dayan <roid@nvidia.com> |
net/mlx5e: TC, Add peer flow in mpesw mode
While at it rename mlx5_lag_mpesw_is_activated() to mlx5_lag_is_mpesw() to be consistent with checking if other lag modes are activated.
Signed-off-by: Ro
net/mlx5e: TC, Add peer flow in mpesw mode
While at it rename mlx5_lag_mpesw_is_activated() to mlx5_lag_is_mpesw() to be consistent with checking if other lag modes are activated.
Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
a32327a3 |
| 28-Nov-2022 |
Roi Dayan <roid@nvidia.com> |
net/mlx5: Lag, Control MultiPort E-Switch single FDB mode
MultiPort E-Switch builds on newer hardware's capabilities and introduces a mode where a single E-Switch is used and all the vports and phys
net/mlx5: Lag, Control MultiPort E-Switch single FDB mode
MultiPort E-Switch builds on newer hardware's capabilities and introduces a mode where a single E-Switch is used and all the vports and physical ports on the NIC are connected to it.
The new mode will allow in the future a decrease in the memory used by the driver and advanced features that aren't possible today.
This represents a big change in the current E-Switch implantation in mlx5. Currently, by default, each E-Switch manager manages its E-Switch. Steering rules in each E-Switch can only forward traffic to the native physical port associated with that E-Switch. While there are ways to target non-native physical ports, for example using a bond or via special TC rules. None of the ways allows a user to configure the driver to operate by default in such a mode nor can the driver decide to move to this mode by default as it's user configuration-driven right now.
While MultiPort E-Switch single FDB mode is the preferred mode, older generations of ConnectX hardware couldn't support this mode so it was never implemented. Now that there is capable hardware present, start the transition to having this mode by default.
Introduce a devlink parameter to control MultiPort E-Switch single FDB mode. This will allow users to select this mode on their system right now and in the future will allow the driver to move to this mode by default.
Example: $ devlink dev param set pci/0000:00:0b.0 name esw_multiport value 1 \ cmode runtime
Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
Revision tags: v6.0.10, v5.15.80 |
|
#
3f26a315 |
| 24-Nov-2022 |
Jiri Pirko <jiri@nvidia.com> |
net/mlx5e: Fix trap event handling
Current code does not return correct return value from event handler. Fix it by returning NOTIFY_* and propagate err over newly introduce ctx structure.
Signed-of
net/mlx5e: Fix trap event handling
Current code does not return correct return value from event handler. Fix it by returning NOTIFY_* and propagate err over newly introduce ctx structure.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
fb8421a9 |
| 27-Jan-2023 |
Jiri Pirko <jiri@nvidia.com> |
devlink: remove devlink features
Devlink features were introduced to disallow devlink reload calls of userspace before the devlink was fully initialized. The reason for this workaround was the fact
devlink: remove devlink features
Devlink features were introduced to disallow devlink reload calls of userspace before the devlink was fully initialized. The reason for this workaround was the fact that devlink reload was originally called without devlink instance lock held.
However, with recent changes that converted devlink reload to be performed under devlink instance lock, this is redundant so remove devlink features entirely.
Note that mlx5 used this to enable devlink reload conditionally only when device didn't act as multi port slave. Move the multi port check into mlx5_devlink_reload_down() callback alongside with the other checks preventing the device from reload in certain states.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
d2a651ef |
| 26-Jan-2023 |
Jiri Pirko <jiri@nvidia.com> |
net/mlx5: Move eswitch port metadata devlink param to flow eswitch code
Move the param registration and handling code into the eswitch offloads code as they are related to each other. No point in ha
net/mlx5: Move eswitch port metadata devlink param to flow eswitch code
Move the param registration and handling code into the eswitch offloads code as they are related to each other. No point in having the devlink param registration done in separate file.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
db492c1e |
| 26-Jan-2023 |
Jiri Pirko <jiri@nvidia.com> |
net/mlx5: Move flow steering devlink param to flow steering code
Move the param registration and handling code into the flow steering code as they are related to each other. No point in having the d
net/mlx5: Move flow steering devlink param to flow steering code
Move the param registration and handling code into the flow steering code as they are related to each other. No point in having the devlink param registration done in separate file.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
c2077fbc |
| 26-Jan-2023 |
Jiri Pirko <jiri@nvidia.com> |
net/mlx5: Move fw reset devlink param to fw reset code
Move the param registration and handling code into the fw reset code as they are related to each other. No point in having the devlink param re
net/mlx5: Move fw reset devlink param to fw reset code
Move the param registration and handling code into the fw reset code as they are related to each other. No point in having the devlink param registration done in separate file.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
075935f0 |
| 26-Jan-2023 |
Jiri Pirko <jiri@nvidia.com> |
devlink: protect devlink param list by instance lock
Commit 1d18bb1a4ddd ("devlink: allow registering parameters after the instance") as the subject implies introduced possibility to register devlin
devlink: protect devlink param list by instance lock
Commit 1d18bb1a4ddd ("devlink: allow registering parameters after the instance") as the subject implies introduced possibility to register devlink params even for already registered devlink instance. This is a bit problematic, as the consistency or params list was originally secured by the fact it is static during devlink lifetime. So in order to protect the params list, take devlink instance lock during the params operations. Introduce unlocked function variants and use them in drivers in locked context. Put lock assertions to appropriate places.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Tested-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
a756185a |
| 26-Jan-2023 |
Jiri Pirko <jiri@nvidia.com> |
net/mlx5: Covert devlink params registration to use devlink_params_register/unregister()
Since mlx5 is the only user of devlink API to register/unregister a single param, convert it to use array reg
net/mlx5: Covert devlink params registration to use devlink_params_register/unregister()
Since mlx5 is the only user of devlink API to register/unregister a single param, convert it to use array registration function allowing to simplify the devlink API by removing the single param registration functions.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
c8aebff4 |
| 26-Jan-2023 |
Jiri Pirko <jiri@nvidia.com> |
net/mlx5: Change devlink param register/unregister function names
The functions are registering and unregistering devlink params, so change the names accordingly.
Signed-off-by: Jiri Pirko <jiri@nv
net/mlx5: Change devlink param register/unregister function names
The functions are registering and unregistering devlink params, so change the names accordingly.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|