#
507472ed |
| 26-Dec-2023 |
Gal Pressman <gal@nvidia.com> |
net/mlx5: Change missing SyncE capability print to debug
Lack of SyncE capability should not emit a warning, change the print to debug level.
Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-b
net/mlx5: Change missing SyncE capability print to debug
Lack of SyncE capability should not emit a warning, change the print to debug level.
Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Jianbo Liu <jianbol@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
b430c1b4 |
| 12-Oct-2023 |
Shay Drory <shayd@nvidia.com> |
net/mlx5: Replace global mlx5_intf_lock with HCA devcom component lock
mlx5_intf_lock is used to sync between LAG changes and its slaves mlx5 core dev aux devices changes, which means every time mlx
net/mlx5: Replace global mlx5_intf_lock with HCA devcom component lock
mlx5_intf_lock is used to sync between LAG changes and its slaves mlx5 core dev aux devices changes, which means every time mlx5 core dev add/remove aux devices, mlx5 is taking this global lock, even if LAG functionality isn't supported over the core dev. This cause a bottleneck when probing VFs/SFs in parallel.
Hence, replace mlx5_intf_lock with HCA devcom component lock, or no lock if LAG functionality isn't supported.
Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
e534552c |
| 12-Oct-2023 |
Shay Drory <shayd@nvidia.com> |
net/mlx5: Refactor LAG peer device lookout bus logic to mlx5 devcom
LAG peer device lookout bus logic required the usage of global lock, mlx5_intf_mutex. As part of the effort to remove this global
net/mlx5: Refactor LAG peer device lookout bus logic to mlx5 devcom
LAG peer device lookout bus logic required the usage of global lock, mlx5_intf_mutex. As part of the effort to remove this global lock, refactor LAG peer device lookout to use mlx5 devcom layer.
Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
496fd0a2 |
| 13-Sep-2023 |
Jiri Pirko <jiri@nvidia.com> |
mlx5: Implement SyncE support using DPLL infrastructure
Implement SyncE support using newly introduced DPLL support. Make sure that each PFs/VFs/SFs probed with appropriate capability will spawn a d
mlx5: Implement SyncE support using DPLL infrastructure
Implement SyncE support using newly introduced DPLL support. Make sure that each PFs/VFs/SFs probed with appropriate capability will spawn a dpll auxiliary device and register appropriate dpll device and pin instances.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Signed-off-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
02ceda65 |
| 13-Jun-2023 |
Roi Dayan <roid@nvidia.com> |
net/mlx5: Use shared code for checking lag is supported
Move shared function to check lag is supported to lag header file.
Signed-off-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <
net/mlx5: Use shared code for checking lag is supported
Move shared function to check lag is supported to lag header file.
Signed-off-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
0d0946d6 |
| 01-Jun-2023 |
Jiri Pirko <jiri@nvidia.com> |
net/mlx5: Remove redundant is_mdev_switchdev_mode() check from is_ib_rep_supported()
is_mdev_switchdev_mode() check is done in is_eth_rep_supported(). Function is_ib_rep_supported() calls is_eth_rep
net/mlx5: Remove redundant is_mdev_switchdev_mode() check from is_ib_rep_supported()
is_mdev_switchdev_mode() check is done in is_eth_rep_supported(). Function is_ib_rep_supported() calls is_eth_rep_supported(). Remove the redundant check from it.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
61955da5 |
| 01-Jun-2023 |
Jiri Pirko <jiri@nvidia.com> |
net/mlx5: Remove redundant MLX5_ESWITCH_MANAGER() check from is_ib_rep_supported()
MLX5_ESWITCH_MANAGER() check is done in is_eth_rep_supported(). Function is_ib_rep_supported() calls is_eth_rep_sup
net/mlx5: Remove redundant MLX5_ESWITCH_MANAGER() check from is_ib_rep_supported()
MLX5_ESWITCH_MANAGER() check is done in is_eth_rep_supported(). Function is_ib_rep_supported() calls is_eth_rep_supported(). Remove the redundant check from it.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
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 ...
|
#
f52cc627 |
| 13-Apr-2023 |
Jakub Kicinski <kuba@kernel.org> |
Revert "net/mlx5: Enable management PF initialization"
This reverts commit fe998a3c77b9f989a30a2a01fb00d3729a6d53a4.
Paul reports that it causes a regression with IB on CX4 and FW 12.18.1000. In ad
Revert "net/mlx5: Enable management PF initialization"
This reverts commit fe998a3c77b9f989a30a2a01fb00d3729a6d53a4.
Paul reports that it causes a regression with IB on CX4 and FW 12.18.1000. In addition I think that the concept of "management PF" is not fully accepted and requires a discussion.
Fixes: fe998a3c77b9 ("net/mlx5: Enable management PF initialization") Reported-by: Paul Moore <paul@paul-moore.com> Link: https://lore.kernel.org/all/CAHC9VhQ7A4+msL38WpbOMYjAqLp0EtOjeLh4Dc6SQtD6OUvCQg@mail.gmail.com/ Link: https://lore.kernel.org/r/20230413222547.56901-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
b637ac5d |
| 03-Jan-2023 |
Eli Cohen <elic@nvidia.com> |
net/mlx5: Use one completion vector if eth is disabled
If eth is disabled by devlink, use only a single completion vector to have minimum performance of all users of completion vectors. This also af
net/mlx5: Use one completion vector if eth is disabled
If eth is disabled by devlink, use only a single completion vector to have minimum performance of all users of completion vectors. This also affects Infiniband performance.
The rest of the vectors can be used by other consumers on a first come first served basis.
mlx5_vdpa will make use of this to allocate dedicated vectors for its own use.
Signed-off-by: Eli Cohen <elic@nvidia.com> Reviewed-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
show more ...
|
#
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 ...
|
#
29a299cb |
| 13-Jan-2023 |
Jiri Pirko <jiri@nvidia.com> |
net/mlx5: Remove outdated comment
The comment is no longer applicable, as the devlink reload and instance cleanup are both protected with devlink instance lock, therefore no race can happen.
Signed
net/mlx5: Remove outdated comment
The comment is no longer applicable, as the devlink reload and instance cleanup are both protected with devlink instance lock, therefore no race can happen.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
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 ...
|
#
65a20c2e |
| 18-Jan-2023 |
Jiri Pirko <jiri@nvidia.com> |
net/mlx5: Remove MLX5E_LOCKED_FLOW flag
The MLX5E_LOCKED_FLOW flag is not checked anywhere now so remove it entirely.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.
net/mlx5: Remove MLX5E_LOCKED_FLOW flag
The MLX5E_LOCKED_FLOW flag is not checked anywhere now so remove it entirely.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
fe998a3c |
| 29-Jun-2022 |
Shay Drory <shayd@nvidia.com> |
net/mlx5: Enable management PF initialization
Enable initialization of DPU Management PF, which is a new loopback PF designed for communication with BMC. For now Management PF doesn't support nor re
net/mlx5: Enable management PF initialization
Enable initialization of DPU Management PF, which is a new loopback PF designed for communication with BMC. For now Management PF doesn't support nor require most upper layer protocols so avoid them.
Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Eran Ben Elisha <eranbe@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
84a433a4 |
| 28-Jul-2022 |
Moshe Shemesh <moshe@nvidia.com> |
net/mlx5: Lock mlx5 devlink reload callbacks
Change devlink instance locks in mlx5 driver to have devlink reload callbacks locked, while keeping all driver paths which lead to devl_ API functions ca
net/mlx5: Lock mlx5 devlink reload callbacks
Change devlink instance locks in mlx5 driver to have devlink reload callbacks locked, while keeping all driver paths which lead to devl_ API functions called by the driver locked.
Add mlx5_load_one_devl_locked() and mlx5_unload_one_devl_locked() which are used by the paths which are already locked such as devlink reload callbacks.
This patch makes the driver use devl_ API also for traps register as these functions are called from the driver paths parallel to reload that requires locking now.
Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
7b19119f |
| 11-Jul-2022 |
Moshe Shemesh <moshe@nvidia.com> |
net/mlx5: Use devl_ API in mlx5e_devlink_port_register
As part of the flows invoked by mlx5_devlink_eswitch_mode_set() get to mlx5_rescan_drivers_locked() which can call mlx5e_probe()/mlx5e_remove a
net/mlx5: Use devl_ API in mlx5e_devlink_port_register
As part of the flows invoked by mlx5_devlink_eswitch_mode_set() get to mlx5_rescan_drivers_locked() which can call mlx5e_probe()/mlx5e_remove and register/unregister mlx5e driver ports accordingly. This can lead to deadlock once mlx5_devlink_eswitch_mode_set() will use devlink lock. Use devl_port_register/unregister() instead of devlink_port_register/unregister() and add devlink instance locks in the driver paths to this function to have it locked while calling devl_ API function.
If remove or probe were called by module init or module cleanup flows, need to lock devlink just before calling devl_port_register(), otherwise it is called by attach/detach or register/unregister flow and we can have the flow locked. Added flag to distinguish between these cases.
This will be used by the downstream patch to invoke mlx5_devlink_eswitch_mode_set() with devlink locked.
Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
show more ...
|
#
3008e6a0 |
| 26-May-2022 |
Mark Bloch <mbloch@nvidia.com> |
net/mlx5: E-Switch, pair only capable devices
OFFLOADS paring using devcom is possible only on devices that support LAG. Filter based on lag capabilities.
This fixes an issue where mlx5_get_next_ph
net/mlx5: E-Switch, pair only capable devices
OFFLOADS paring using devcom is possible only on devices that support LAG. Filter based on lag capabilities.
This fixes an issue where mlx5_get_next_phys_dev() was called without holding the interface lock.
This issue was found when commit bc4c2f2e0179 ("net/mlx5: Lag, filter non compatible devices") added an assert that verifies the interface lock is held.
WARNING: CPU: 9 PID: 1706 at drivers/net/ethernet/mellanox/mlx5/core/dev.c:642 mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core] Modules linked in: mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm ib_uverbs ib_core overlay fuse [last unloaded: mlx5_core] CPU: 9 PID: 1706 Comm: devlink Not tainted 5.18.0-rc7+ #11 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core] Code: 02 00 75 48 48 8b 85 80 04 00 00 5d c3 31 c0 5d c3 be ff ff ff ff 48 c7 c7 08 41 5b a0 e8 36 87 28 e3 85 c0 0f 85 6f ff ff ff <0f> 0b e9 68 ff ff ff 48 c7 c7 0c 91 cc 84 e8 cb 36 6f e1 e9 4d ff RSP: 0018:ffff88811bf47458 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88811b398000 RCX: 0000000000000001 RDX: 0000000080000000 RSI: ffffffffa05b4108 RDI: ffff88812daaaa78 RBP: ffff88812d050380 R08: 0000000000000001 R09: ffff88811d6b3437 R10: 0000000000000001 R11: 00000000fddd3581 R12: ffff88815238c000 R13: ffff88812d050380 R14: ffff8881018aa7e0 R15: ffff88811d6b3428 FS: 00007fc82e18ae80(0000) GS:ffff88842e080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9630d1b421 CR3: 0000000149802004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> mlx5_esw_offloads_devcom_event+0x99/0x3b0 [mlx5_core] mlx5_devcom_send_event+0x167/0x1d0 [mlx5_core] esw_offloads_enable+0x1153/0x1500 [mlx5_core] ? mlx5_esw_offloads_controller_valid+0x170/0x170 [mlx5_core] ? wait_for_completion_io_timeout+0x20/0x20 ? mlx5_rescan_drivers_locked+0x318/0x810 [mlx5_core] mlx5_eswitch_enable_locked+0x586/0xc50 [mlx5_core] ? mlx5_eswitch_disable_pf_vf_vports+0x1d0/0x1d0 [mlx5_core] ? mlx5_esw_try_lock+0x1b/0xb0 [mlx5_core] ? mlx5_eswitch_enable+0x270/0x270 [mlx5_core] ? __debugfs_create_file+0x260/0x3e0 mlx5_devlink_eswitch_mode_set+0x27e/0x870 [mlx5_core] ? mutex_lock_io_nested+0x12c0/0x12c0 ? esw_offloads_disable+0x250/0x250 [mlx5_core] ? devlink_nl_cmd_trap_get_dumpit+0x470/0x470 ? rcu_read_lock_sched_held+0x3f/0x70 devlink_nl_cmd_eswitch_set_doit+0x217/0x620
Fixes: dd3fddb82780 ("net/mlx5: E-Switch, handle devcom events only for ports on the same device") Signed-off-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
1c5de097 |
| 20-Feb-2021 |
Saeed Mahameed <saeedm@nvidia.com> |
net/mlx5: Fix mlx5_get_next_dev() peer device matching
In some use-cases, mlx5 instances will need to search for their peer device (the other port on the same HCA). For that, mlx5 device matching me
net/mlx5: Fix mlx5_get_next_dev() peer device matching
In some use-cases, mlx5 instances will need to search for their peer device (the other port on the same HCA). For that, mlx5 device matching mechanism relied on auxiliary_find_device() to search, and used a bad matching callback function.
This approach has two issues:
1) next_phys_dev() the matching function, assumed all devices are of the type mlx5_adev (mlx5 auxiliary device) which is wrong and could lead to crashes, this worked for a while, since only lately other drivers started registering auxiliary devices.
2) using the auxiliary class bus (auxiliary_find_device) to search for mlx5_core_dev devices, who are actually PCIe device instances, is wrong. This works since mlx5_core always has at least one mlx5_adev instance hanging around in the aux bus.
As suggested by others we can fix 1. by comparing device names prefixes if they have the string "mlx5_core" in them, which is not a best practice ! but even with that fixed, still 2. needs fixing, we are trying to match pcie device peers so we should look in the right bus (pci bus), hence this fix.
The fix: 1) search the pci bus for mlx5 peer devices, instead of the aux bus 2) to validated devices are the same type "mlx5_core_dev" compare if they have the same driver, which is bulletproof.
This wouldn't have worked with the aux bus since the various mlx5 aux device types don't share the same driver, even if they share the same device wrapper struct (mlx5_adev) "which helped to find the parent device"
Fixes: a925b5e309c9 ("net/mlx5: Register mlx5 devices to auxiliary virtual bus") Reported-by: Alexander Lobakin <alexandr.lobakin@intel.com> Reported-by: Maher Sanalla <msanalla@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
show more ...
|
#
4cd14d44 |
| 01-Mar-2022 |
Mark Bloch <mbloch@nvidia.com> |
net/mlx5: Support devices with more than 2 ports
Increase the define MLX5_MAX_PORTS to 4 as the driver is ready to support NICs with 4 ports.
Signed-off-by: Mark Bloch <mbloch@nvidia.com> Reviewed-
net/mlx5: Support devices with more than 2 ports
Increase the define MLX5_MAX_PORTS to 4 as the driver is ready to support NICs with 4 ports.
Signed-off-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Maor Gottlieb <maorg@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
bc4c2f2e |
| 27-Feb-2022 |
Mark Bloch <mbloch@nvidia.com> |
net/mlx5: Lag, filter non compatible devices
When search for a peer lag device we can filter based on that device's capabilities.
Downstream patch will be less strict when filtering compatible devi
net/mlx5: Lag, filter non compatible devices
When search for a peer lag device we can filter based on that device's capabilities.
Downstream patch will be less strict when filtering compatible devices and remove the limitation where we require exact MLX5_MAX_PORTS and change it to a range.
Signed-off-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Maor Gottlieb <maorg@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
c9c079b4 |
| 03-Jan-2022 |
Paul Blakey <paulb@nvidia.com> |
net/mlx5: CT: Set flow source hint from provided tuple device
Get originating device from tuple offload metadata match ingress_ifindex, and set flow_source hint to either LOCAL for vf/sf reps, UPLIN
net/mlx5: CT: Set flow source hint from provided tuple device
Get originating device from tuple offload metadata match ingress_ifindex, and set flow_source hint to either LOCAL for vf/sf reps, UPLINK for uplink/wire/tunnel devices/bond, or ANY (as before this patch) for all others.
This allows lower layer (software steering or firmware) to insert the tuple rule only in one table (either rx or tx) instead of two (rx and tx).
Signed-off-by: Paul Blakey <paulb@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
8a543184 |
| 12-Oct-2021 |
Rongwei Liu <rongweil@nvidia.com> |
net/mlx5: Use system_image_guid to determine bonding
With specific NICs, the PFs may have different PCIe ids like 0001:01:00.0/1 and 0002:02:00:00/1.
For PFs with the same system_image_guid, driver
net/mlx5: Use system_image_guid to determine bonding
With specific NICs, the PFs may have different PCIe ids like 0001:01:00.0/1 and 0002:02:00:00/1.
For PFs with the same system_image_guid, driver should consider them under the same physical NIC and they are legal to bond together.
If firmware doesn't support system_image_guid, set it to zero and fallback to use PCIe ids.
Signed-off-by: Rongwei Liu <rongweil@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
8e7e2e8e |
| 21-Aug-2021 |
Leon Romanovsky <leonro@nvidia.com> |
net/mlx5: Remove all auxiliary devices at the unregister event
The call to mlx5_unregister_device() means that mlx5_core driver is removed. In such scenario, we need to disregard all other flags lik
net/mlx5: Remove all auxiliary devices at the unregister event
The call to mlx5_unregister_device() means that mlx5_core driver is removed. In such scenario, we need to disregard all other flags like attach/detach and forcibly remove all auxiliary devices.
Fixes: a5ae8fc9058e ("net/mlx5e: Don't create devices during unload flow") Tested-and-Reported-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
70862a5d |
| 10-Aug-2021 |
Parav Pandit <parav@nvidia.com> |
net/mlx5: Support enable_vnet devlink dev param
Enable user to disable VDPA net auxiliary device so that when it is not required, user can disable it.
For example,
$ devlink dev param set pci/0000
net/mlx5: Support enable_vnet devlink dev param
Enable user to disable VDPA net auxiliary device so that when it is not required, user can disable it.
For example,
$ devlink dev param set pci/0000:06:00.0 \ name enable_vnet value false cmode driverinit $ devlink dev reload pci/0000:06:00.0
At this point devlink instance do not create auxiliary device mlx5_core.vnet.2 for the VDPA net functionality.
Signed-off-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|