#
f2b41b32 |
| 06-Apr-2022 |
Leon Romanovsky <leonro@nvidia.com> |
net/mlx5: Remove ipsec_ops function table
There is only one IPsec implementation and ipsec_ops is not needed at all in this situation. Together with removal of ipsec_ops, we can drop the entry check
net/mlx5: Remove ipsec_ops function table
There is only one IPsec implementation and ipsec_ops is not needed at all in this situation. Together with removal of ipsec_ops, we can drop the entry checks as these functions are called for IPsec devices only.
Link: https://lore.kernel.org/r/bc8dd1c8a77b65dbf5e2cf92c813ffaca2505c5f.1649232994.git.leonro@nvidia.com Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
show more ...
|
#
16fe5a1c |
| 06-Apr-2022 |
Leon Romanovsky <leonro@nvidia.com> |
net/mlx5: Move IPsec file to relevant directory
IPsec is part of ethernet side of mlx5 driver and needs to be placed in en_accel folder.
Link: https://lore.kernel.org/r/a0ca88f4d9c602c574106c0de051
net/mlx5: Move IPsec file to relevant directory
IPsec is part of ethernet side of mlx5 driver and needs to be placed in en_accel folder.
Link: https://lore.kernel.org/r/a0ca88f4d9c602c574106c0de0511803e7dcbdff.1649232994.git.leonro@nvidia.com Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
show more ...
|
#
7e4e8491 |
| 06-Apr-2022 |
Leon Romanovsky <leonro@nvidia.com> |
net/mlx5: Remove ipsec vs. ipsec offload file separation
The IPsec won't be initialized at all if device doesn't support IPsec offload. It means that we can combine the ipsec.c and ipsec_offload.c f
net/mlx5: Remove ipsec vs. ipsec offload file separation
The IPsec won't be initialized at all if device doesn't support IPsec offload. It means that we can combine the ipsec.c and ipsec_offload.c files to one file. Such change will allow us to remove ipsec_ops indirection.
Link: https://lore.kernel.org/r/d0ac1fb7b14c10ae20a21ae17a393ee860c72ac3.1649232994.git.leonro@nvidia.com Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
show more ...
|
#
2fa33b35 |
| 06-Apr-2022 |
Leon Romanovsky <leonro@nvidia.com> |
net/mlx5_fpga: Drop INNOVA IPsec support
Mellanox INNOVA IPsec cards are EOL in Nov, 2019 [1]. As such, the code is unmaintained, untested and not in-use by any upstream/distro oriented customers. I
net/mlx5_fpga: Drop INNOVA IPsec support
Mellanox INNOVA IPsec cards are EOL in Nov, 2019 [1]. As such, the code is unmaintained, untested and not in-use by any upstream/distro oriented customers. In order to reduce code complexity, drop the kernel code.
[1] https://network.nvidia.com/related-docs/eol/LCR-000535.pdf
Link: https://lore.kernel.org/r/2afe88ec5020a491079eacf6fe3c89b64d65195c.1649232994.git.leonro@nvidia.com Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
show more ...
|
#
40379a00 |
| 04-Apr-2022 |
Leon Romanovsky <leonro@nvidia.com> |
net/mlx5_fpga: Drop INNOVA TLS support
Mellanox INNOVA TLS cards are EOL in May, 2018 [1]. As such, the code is unmaintained, untested and not in-use by any upstream/distro oriented customers. In or
net/mlx5_fpga: Drop INNOVA TLS support
Mellanox INNOVA TLS cards are EOL in May, 2018 [1]. As such, the code is unmaintained, untested and not in-use by any upstream/distro oriented customers. In order to reduce code complexity, drop the kernel code.
[1] https://network.nvidia.com/related-docs/eol/LCR-000286.pdf
Link: https://lore.kernel.org/r/b88add368def721ea9d054cb69def72d9e3f67aa.1649073691.git.leonro@nvidia.com Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
show more ...
|
#
66771a1c |
| 18-Feb-2022 |
Moshe Shemesh <moshe@nvidia.com> |
net/mlx5: Move debugfs entries to separate struct
Move the debugfs entry pointers under priv to their own struct. Add get function for device debugfs root.
Signed-off-by: Moshe Shemesh <moshe@nvidi
net/mlx5: Move debugfs entries to separate struct
Move the debugfs entry pointers under priv to their own struct. Add get function for device debugfs root.
Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
1695b97b |
| 24-Feb-2022 |
Yishai Hadas <yishaih@nvidia.com> |
net/mlx5: Expose APIs to get/put the mlx5 core device
Expose an API to get the mlx5 core device from a given VF PCI device if mlx5_core is its driver.
Upon the get API we stay with the intf_state_m
net/mlx5: Expose APIs to get/put the mlx5 core device
Expose an API to get the mlx5 core device from a given VF PCI device if mlx5_core is its driver.
Upon the get API we stay with the intf_state_mutex locked to make sure that the device can't be gone/unloaded till the caller will complete its job over the device, this expects to be for a short period of time for any flow that the lock is taken.
Upon the put API we unlock the intf_state_mutex.
The use case for those APIs is the migration flow of a VF over VFIO PCI. In that case the VF doesn't ride on mlx5_core, because the device is driving *two* different PCI devices, the PF owned by mlx5_core and the VF owned by the vfio driver.
The mlx5_core of the PF is accessed only during the narrow window of the VF's ioctl that requires its services.
This allows the PF driver to be more independent of the VF driver, so long as it doesn't reset the FW.
Link: https://lore.kernel.org/all/20220224142024.147653-6-yishaih@nvidia.com Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
show more ...
|
#
143a41d7 |
| 24-Feb-2022 |
Yishai Hadas <yishaih@nvidia.com> |
net/mlx5: Disable SRIOV before PF removal
Virtual functions depend on physical function for device access (for example firmware host PAGE management), so make sure to disable SR-IOV once PF is gone.
net/mlx5: Disable SRIOV before PF removal
Virtual functions depend on physical function for device access (for example firmware host PAGE management), so make sure to disable SR-IOV once PF is gone.
This will prevent also the below warning if PF has gone before disabling SR-IOV. "driver left SR-IOV enabled after remove"
Next patch from this series will rely on that when the VF may need to access safely the PF 'driver data'.
Link: https://lore.kernel.org/all/20220224142024.147653-4-yishaih@nvidia.com Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
show more ...
|
#
7f839965 |
| 16-Feb-2022 |
Maher Sanalla <msanalla@nvidia.com> |
net/mlx5: Update log_max_qp value to be 17 at most
Currently, log_max_qp value is dependent on what FW reports as its max capability. In reality, due to a bug, some FWs report a value greater than 1
net/mlx5: Update log_max_qp value to be 17 at most
Currently, log_max_qp value is dependent on what FW reports as its max capability. In reality, due to a bug, some FWs report a value greater than 17, even though they don't support log_max_qp > 17.
This FW issue led the driver to exhaust memory on startup. Thus, log_max_qp value is set to be no more than 17 regardless of what FW reports, as it was before the cited commit.
Fixes: f79a609ea6bf ("net/mlx5: Update log_max_qp value to FW max capability") Signed-off-by: Maher Sanalla <msanalla@nvidia.com> Reviewed-by: Avihai Horon <avihaih@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
f908a35b |
| 10-Jan-2022 |
Meir Lichtinger <meirl@nvidia.com> |
net/mlx5: Update the list of the PCI supported devices
Add the upcoming BlueField-4 and ConnectX-8 device IDs.
Fixes: 2e9d3e83ab82 ("net/mlx5: Update the list of the PCI supported devices") Signed-
net/mlx5: Update the list of the PCI supported devices
Add the upcoming BlueField-4 and ConnectX-8 device IDs.
Fixes: 2e9d3e83ab82 ("net/mlx5: Update the list of the PCI supported devices") Signed-off-by: Meir Lichtinger <meirl@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
Revision tags: v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31 |
|
#
605bef00 |
| 05-Apr-2020 |
Saeed Mahameed <saeedm@mellanox.com> |
net/mlx5: cmdif, cmd_check refactoring
Do not mangle the command outbox in the internal low level cmd_exec and cmd_invoke functions.
Instead return a proper unique error code and move the driver er
net/mlx5: cmdif, cmd_check refactoring
Do not mangle the command outbox in the internal low level cmd_exec and cmd_invoke functions.
Instead return a proper unique error code and move the driver error checking to be at a higher level in mlx5_cmd_exec().
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
f79a609e |
| 05-Jan-2022 |
Maher Sanalla <msanalla@nvidia.com> |
net/mlx5: Update log_max_qp value to FW max capability
log_max_qp in driver's default profile #2 was set to 18, but FW actually supports 17 at the most - a situation that led to the concerning print
net/mlx5: Update log_max_qp value to FW max capability
log_max_qp in driver's default profile #2 was set to 18, but FW actually supports 17 at the most - a situation that led to the concerning print when the driver is loaded: "log_max_qp value in current profile is 18, changing to HCA capabaility limit (17)"
The expected behavior from mlx5_profile #2 is to match the maximum FW capability in regards to log_max_qp. Thus, log_max_qp in profile #2 is initialized to a defined static value (0xff) - which basically means that when loading this profile, log_max_qp value will be what the currently installed FW supports at most.
Signed-off-by: Maher Sanalla <msanalla@nvidia.com> Reviewed-by: Maor Gottlieb <maorg@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
33de865f |
| 23-Nov-2021 |
Moshe Shemesh <moshe@nvidia.com> |
net/mlx5: Fix SF health recovery flow
SF do not directly control the PCI device. During recovery flow SF should not be allowed to do pci disable or pci reset, its PF will do it.
It fixes the follow
net/mlx5: Fix SF health recovery flow
SF do not directly control the PCI device. During recovery flow SF should not be allowed to do pci disable or pci reset, its PF will do it.
It fixes the following kernel trace: mlx5_core.sf mlx5_core.sf.25: mlx5_health_try_recover:387:(pid 40948): starting health recovery flow mlx5_core 0000:03:00.0: mlx5_pci_slot_reset was called mlx5_core 0000:03:00.0: wait vital counter value 0xab175 after 1 iterations mlx5_core.sf mlx5_core.sf.25: firmware version: 24.32.532 mlx5_core.sf mlx5_core.sf.23: mlx5_health_try_recover:387:(pid 40946): starting health recovery flow mlx5_core 0000:03:00.0: mlx5_pci_slot_reset was called mlx5_core 0000:03:00.0: wait vital counter value 0xab193 after 1 iterations mlx5_core.sf mlx5_core.sf.23: firmware version: 24.32.532 mlx5_core.sf mlx5_core.sf.25: mlx5_cmd_check:813:(pid 40948): ENABLE_HCA(0x104) op_mod(0x0) failed, status bad resource state(0x9), syndrome (0x658908) mlx5_core.sf mlx5_core.sf.25: mlx5_function_setup:1292:(pid 40948): enable hca failed mlx5_core.sf mlx5_core.sf.25: mlx5_health_try_recover:389:(pid 40948): health recovery failed
Fixes: 1958fc2f0712 ("net/mlx5: SF, Add auxiliary device driver") Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
8680a60f |
| 09-Dec-2021 |
Shay Drory <shayd@nvidia.com> |
net/mlx5: Let user configure max_macs generic param
Currently, max_macs is taking 70Kbytes of memory per function. This size is not needed in all use cases, and is critical with large scale. Hence,
net/mlx5: Let user configure max_macs generic param
Currently, max_macs is taking 70Kbytes of memory per function. This size is not needed in all use cases, and is critical with large scale. Hence, allow user to configure the number of max_macs.
For example, to reduce the number of max_macs to 1, execute:: $ devlink dev param set pci/0000:00:0b.0 name max_macs value 1 \ cmode driverinit $ devlink dev reload pci/0000:00:0b.0
Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
fad1783a |
| 04-Oct-2021 |
Saeed Mahameed <saeedm@nvidia.com> |
net/mlx5: Print more info on pci error handlers
In case mlx5_pci_err_detected was called with state equals to pci_channel_io_perm_failure, the driver will never come back up.
It is nice to know why
net/mlx5: Print more info on pci error handlers
In case mlx5_pci_err_detected was called with state equals to pci_channel_io_perm_failure, the driver will never come back up.
It is nice to know why the driver went to zombie land, so print some useful information on pci err handlers.
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
show more ...
|
#
502e82b9 |
| 07-Nov-2021 |
Aya Levin <ayal@nvidia.com> |
net/mlx5: Fix access to a non-supported register
Validate MRTC register is supported before triggering a delayed work which accesses it.
Fixes: 5a1023deeed0 ("net/mlx5: Add periodic update of host
net/mlx5: Fix access to a non-supported register
Validate MRTC register is supported before triggering a delayed work which accesses it.
Fixes: 5a1023deeed0 ("net/mlx5: Add periodic update of host time to firmware") Signed-off-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
76091b0f |
| 20-Oct-2021 |
Amir Tzin <amirtz@nvidia.com> |
net/mlx5: Fix use after free in mlx5_health_wait_pci_up
The device health recovery flow calls mlx5_health_wait_pci_up() which queries the device for FW_RESET timeout after freeing the device timeout
net/mlx5: Fix use after free in mlx5_health_wait_pci_up
The device health recovery flow calls mlx5_health_wait_pci_up() which queries the device for FW_RESET timeout after freeing the device timeouts structure on mlx5_function_teardown(). Fix this bug by moving timeouts structure init/cleanup to the device's init/uninit phases. Since it is necessary to reset default software timeouts on function reload, extract setting of defaults values from mlx5_tout_init() and call mlx5_tout_set_def_val() directly from mlx5_function_setup().
Fixes: 5945e1adeab5 ("net/mlx5: Read timeout values from init segment") Reported by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Amir Tzin <amirtz@nvidia.com> Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
7025329d |
| 09-Sep-2020 |
Ben Ben-Ishay <benishay@nvidia.com> |
net/mlx5: Add SHAMPO caps, HW bits and enumerations
This commit adds SHAMPO bit to hca_cap and SHAMPO capabilities structure, SHAMPO related HW spec hardware fields and enumerations. SHAMPO stands f
net/mlx5: Add SHAMPO caps, HW bits and enumerations
This commit adds SHAMPO bit to hca_cap and SHAMPO capabilities structure, SHAMPO related HW spec hardware fields and enumerations. SHAMPO stands for: split headers and merge payload offload. SHAMPO new fields: WQ: - headers_mkey: mkey that represents the headers buffer, where the packets headers will be written by the HW.
- shampo_enable: flag to verify if the WQ supports SHAMPO feature.
- log_reservation_size: the log of the reservation size where the data of the packet will be written by the HW.
- log_max_num_of_packets_per_reservation: log of the maximum number of packets that can be written to the same reservation.
- log_headers_entry_size: log of the header entry size of the headers buffer.
- log_headers_buffer_entry_num: log of the entries number of the headers buffer.
RQ: - shampo_no_match_alignment_granularity: the HW alignment granularity in case the received packet doesn't match the current session.
- shampo_match_criteria_type: the type of match criteria.
- reservation_timeout: the maximum time that the HW will hold the reservation.
mlx5_ifc_shampo_cap_bits, the capabilities of the SHAMPO feature: - shampo_log_max_reservation_size: the maximum allowed value of the field WQ.log_reservation_size.
- log_reservation_size: the minimum allowed value of the field WQ.log_reservation_size.
- shampo_min_mss_size: the minimum payload size of packet that can open a new session or be merged to a session.
- shampo_max_log_headers_entry_size: the maximum allowed value of the field WQ.log_headers_entry_size
Signed-off-by: Ben Ben-Ishay <benishay@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
6b367174 |
| 26-Oct-2021 |
Jakub Kicinski <kuba@kernel.org> |
net/mlx5: remove the recent devlink params
revert commit 46ae40b94d88 ("net/mlx5: Let user configure io_eq_size param") revert commit a6cb08daa3b4 ("net/mlx5: Let user configure event_eq_size param"
net/mlx5: remove the recent devlink params
revert commit 46ae40b94d88 ("net/mlx5: Let user configure io_eq_size param") revert commit a6cb08daa3b4 ("net/mlx5: Let user configure event_eq_size param") revert commit 554604061979 ("net/mlx5: Let user configure max_macs param")
The EQE parameters are applicable to more drivers, they should be configured via standard API, probably ethtool. Example of another driver needing something similar:
https://lore.kernel.org/all/1633454136-14679-3-git-send-email-sbhatta@marvell.com/
The last param for "max_macs" is probably fine but the documentation is severely lacking. The meaning and implications for changing the param need to be stated.
Link: https://lore.kernel.org/r/20211026152939.3125950-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
55460406 |
| 16-Aug-2021 |
Shay Drory <shayd@nvidia.com> |
net/mlx5: Let user configure max_macs param
Currently, max_macs is taking 70Kbytes of memory per function. This size is not needed in all use cases, and is critical with large scale. Hence, allow us
net/mlx5: Let user configure max_macs param
Currently, max_macs is taking 70Kbytes of memory per function. This size is not needed in all use cases, and is critical with large scale. Hence, allow user to configure the number of max_macs.
For example, to reduce the number of max_macs to 1, execute:: $ devlink dev param set pci/0000:00:0b.0 name max_macs value 1 \ cmode driverinit $ devlink dev reload pci/0000:00:0b.0
Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
46ae40b9 |
| 12-Aug-2021 |
Shay Drory <shayd@nvidia.com> |
net/mlx5: Let user configure io_eq_size param
Currently, each I/O EQ is taking 128KB of memory. This size is not needed in all use cases, and is critical with large scale. Hence, allow user to confi
net/mlx5: Let user configure io_eq_size param
Currently, each I/O EQ is taking 128KB of memory. This size is not needed in all use cases, and is critical with large scale. Hence, allow user to configure the size of I/O EQs.
For example, to reduce I/O EQ size to 64, execute: $ devlink resource set pci/0000:00:0b.0 path /io_eq_size/ size 64 $ devlink dev reload pci/0000:00:0b.0
Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
425a563a |
| 23-May-2021 |
Maor Gottlieb <maorg@nvidia.com> |
net/mlx5: Introduce port selection namespace
Add new port selection flow steering namespace. Flow steering rules in this namespaceare are used to determine the physical port for egress packets.
Sig
net/mlx5: Introduce port selection namespace
Add new port selection flow steering namespace. Flow steering rules in this namespaceare are used to determine the physical port for egress packets.
Signed-off-by: Maor Gottlieb <maorg@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
fbfa97b4 |
| 18-Aug-2021 |
Shay Drory <shayd@nvidia.com> |
net/mlx5: Disable roce at HCA level
Currently, when a user disables roce via the devlink param, this change isn't passed down to the device. If device allows disabling RoCE at device level, make use
net/mlx5: Disable roce at HCA level
Currently, when a user disables roce via the devlink param, this change isn't passed down to the device. If device allows disabling RoCE at device level, make use of it. This instructs the device to skip memory allocations related to RoCE functionality which otherwise is done by the device.
Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
32def412 |
| 13-Oct-2021 |
Amir Tzin <amirtz@nvidia.com> |
net/mlx5: Read timeout values from DTOR
Replace hard coded timeouts with values stored by firmware in default timeouts register (DTOR). Timeouts are read during driver load. If DTOR is not supported
net/mlx5: Read timeout values from DTOR
Replace hard coded timeouts with values stored by firmware in default timeouts register (DTOR). Timeouts are read during driver load. If DTOR is not supported by firmware then fallback to hard coded defaults instead.
Signed-off-by: Amir Tzin <amirtz@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
5945e1ad |
| 07-Oct-2021 |
Amir Tzin <amirtz@mellanox.com> |
net/mlx5: Read timeout values from init segment
Replace hard coded timeouts with values stored in firmware's init segment. Timeouts are read from init segment during driver load. If init segment tim
net/mlx5: Read timeout values from init segment
Replace hard coded timeouts with values stored in firmware's init segment. Timeouts are read from init segment during driver load. If init segment timeouts are not supported then fallback to hard coded defaults instead. Also move pre initialization timeouts which cannot be read from firmware to the new mechanism.
Signed-off-by: Amir Tzin <amirtz@mellanox.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|