Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, 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 |
|
#
0212e5d9 |
| 25-Jul-2023 |
Joe Damato <jdamato@fastly.com> |
net/mlx5: Fix flowhash key set/get for custom RSS
mlx5 flow hash field retrieval and set only worked on the default RSS context as of commit f01cc58c18d6 ("net/mlx5e: Support multiple RSS contexts")
net/mlx5: Fix flowhash key set/get for custom RSS
mlx5 flow hash field retrieval and set only worked on the default RSS context as of commit f01cc58c18d6 ("net/mlx5e: Support multiple RSS contexts"), not custom RSS contexts.
For example, before this patch attempting to retrieve the flow hash fields for RSS context 1 fails:
$ sudo ethtool -u eth1 rx-flow-hash tcp4 context 1 Cannot get RX network flow hashing options: Invalid argument
This patch fixes getting and setting the flow hash fields for contexts other than the default context.
Getting the flow hash fields for RSS context 1:
$ sudo ethtool -u eth1 rx-flow-hash tcp4 context 1 For RSS context 1: TCP over IPV4 flows use these fields for computing Hash flow key: IP DA
Now, setting the flash hash fields to a custom value:
$ sudo ethtool -U eth1 rx-flow-hash tcp4 sdfn context 1
And retrieving them again:
$ sudo ethtool -u eth1 rx-flow-hash tcp4 context 1 For RSS context 1: TCP over IPV4 flows use these fields for computing Hash flow key: IP SA IP DA L4 bytes 0 & 1 [TCP/UDP src port] L4 bytes 2 & 3 [TCP/UDP dst port]
Signed-off-by: Joe Damato <jdamato@fastly.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: 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, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, 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, 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, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0 |
|
#
3db4c85c |
| 30-Sep-2022 |
Maxim Mikityanskiy <maximmi@nvidia.com> |
net/mlx5e: xsk: Use queue indices starting from 0 for XSK queues
In the initial implementation of XSK in mlx5e, XSK RQs coexisted with regular RQs in the same channel. The main idea was to allow RSS
net/mlx5e: xsk: Use queue indices starting from 0 for XSK queues
In the initial implementation of XSK in mlx5e, XSK RQs coexisted with regular RQs in the same channel. The main idea was to allow RSS work the same for regular traffic, without need to reconfigure RSS to exclude XSK queues.
However, this scheme didn't prove to be beneficial, mainly because of incompatibility with other vendors. Some tools don't properly support using higher indices for XSK queues, some tools get confused with the double amount of RQs exposed in sysfs. Some use cases are purely XSK, and allocating the same amount of unused regular RQs is a waste of resources.
This commit changes the queuing scheme to the standard one, where XSK RQs replace regular RQs on the channels where XSK sockets are open. Two RQs still exist in the channel to allow failsafe disable of XSK, but only one is exposed at a time. The next commit will achieve the desired memory save by flushing the buffers when the regular RQ is unused.
As the result of this transition:
1. It's possible to use RSS contexts over XSK RQs.
2. It's possible to dedicate all queues to XSK.
3. When XSK RQs coexist with regular RQs, the admin should make sure no unwanted traffic goes into XSK RQs by either excluding them from RSS or settings up the XDP program to return XDP_PASS for non-XSK traffic.
4. When using a mixed fleet of mlx5e devices and other netdevs, the same configuration can be applied. If the application supports the fallback to copy mode on unsupported drivers, it will work too.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
Revision tags: v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65 |
|
#
4cce2ccf |
| 13-Sep-2021 |
Tariq Toukan <tariqt@nvidia.com> |
net/mlx5e: Sync TIR params updates against concurrent create/modify
Transport Interface Receive (TIR) objects perform the packet processing and reassembly and is also responsible for demultiplexing
net/mlx5e: Sync TIR params updates against concurrent create/modify
Transport Interface Receive (TIR) objects perform the packet processing and reassembly and is also responsible for demultiplexing the packets into the different RQs.
There are certain TIR context attributes that propagate to the pointed RQs and applied to them (like packet_merge offloads (LRO/SHAMPO) and tunneled_offload_en). When TIRs do not agree on attributes values, a "last one wins" policy is applied. Hence, if not synced properly, a race between TIR params update and a concurrent TIR create/modify operation might yield to a mismatch between the shadow parameters in SW and the actual applied state of the RQs in HW.
tunneled_offload_en is a fixed attribute per profile, while packet merge offload state might be toggled and get out-of-sync. When this happens, packet_merge offload might be working although not requested, or the opposite.
All updates to packet_merge state and all create/modify operations of regular redirection/steering TIRs are done under the same priv->state_lock, so they do not run in parallel, and no race is possible.
However, there are other kind of TIRs (acceleration offloads TIRs, like TLS TIRs) which are created on demand for each new connection without holding the coarse priv->state_lock, hence might race.
Fix this by synchronizing all packet_merge state reads and writes against all TIR create/modify operations. Include the modify operations of the regular redirection steering TIRs under the new lock, for better code layering and division of responsibilities.
Fixes: 1182f3659357 ("net/mlx5e: kTLS, Add kTLS RX HW offload support") Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
Revision tags: v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43 |
|
#
eaee12f0 |
| 09-Jun-2021 |
Khalid Manaa <khalidm@nvidia.com> |
net/mlx5e: Rename TIR lro functions to TIR packet merge functions
This series introduces new packet merge type, therefore rename lro functions to packet merge to support the new merge type: - Genera
net/mlx5e: Rename TIR lro functions to TIR packet merge functions
This series introduces new packet merge type, therefore rename lro functions to packet merge to support the new merge type: - Generalize + rename mlx5e_build_tir_ctx_lro to mlx5e_build_tir_ctx_packet_merge. - Rename mlx5e_modify_tirs_lro to mlx5e_modify_tirs_packet_merge. - Rename lro bit in mlx5_ifc_modify_tir_bitmask_bits to packet_merge. - Rename lro_en in mlx5e_params to packet_merge_type type and combine packet_merge params into one struct mlx5e_packet_merge_param.
Signed-off-by: Khalid Manaa <khalidm@nvidia.com> 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 ...
|
#
cb0fb54f |
| 13-Sep-2021 |
Tariq Toukan <tariqt@nvidia.com> |
net/mlx5e: Sync TIR params updates against concurrent create/modify
[ Upstream commit 4cce2ccf08fbc27ae34ce0e72db15166e7b5f6a7 ]
Transport Interface Receive (TIR) objects perform the packet process
net/mlx5e: Sync TIR params updates against concurrent create/modify
[ Upstream commit 4cce2ccf08fbc27ae34ce0e72db15166e7b5f6a7 ]
Transport Interface Receive (TIR) objects perform the packet processing and reassembly and is also responsible for demultiplexing the packets into the different RQs.
There are certain TIR context attributes that propagate to the pointed RQs and applied to them (like packet_merge offloads (LRO/SHAMPO) and tunneled_offload_en). When TIRs do not agree on attributes values, a "last one wins" policy is applied. Hence, if not synced properly, a race between TIR params update and a concurrent TIR create/modify operation might yield to a mismatch between the shadow parameters in SW and the actual applied state of the RQs in HW.
tunneled_offload_en is a fixed attribute per profile, while packet merge offload state might be toggled and get out-of-sync. When this happens, packet_merge offload might be working although not requested, or the opposite.
All updates to packet_merge state and all create/modify operations of regular redirection/steering TIRs are done under the same priv->state_lock, so they do not run in parallel, and no race is possible.
However, there are other kind of TIRs (acceleration offloads TIRs, like TLS TIRs) which are created on demand for each new connection without holding the coarse priv->state_lock, hence might race.
Fix this by synchronizing all packet_merge state reads and writes against all TIR create/modify operations. Include the modify operations of the regular redirection steering TIRs under the new lock, for better code layering and division of responsibilities.
Fixes: 1182f3659357 ("net/mlx5e: kTLS, Add kTLS RX HW offload support") Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
a950a93b |
| 09-Jun-2021 |
Khalid Manaa <khalidm@nvidia.com> |
net/mlx5e: Rename TIR lro functions to TIR packet merge functions
[ Upstream commit eaee12f046924eeb1210c7e4f3b326603ff1bd85 ]
This series introduces new packet merge type, therefore rename lro fun
net/mlx5e: Rename TIR lro functions to TIR packet merge functions
[ Upstream commit eaee12f046924eeb1210c7e4f3b326603ff1bd85 ]
This series introduces new packet merge type, therefore rename lro functions to packet merge to support the new merge type: - Generalize + rename mlx5e_build_tir_ctx_lro to mlx5e_build_tir_ctx_packet_merge. - Rename mlx5e_modify_tirs_lro to mlx5e_modify_tirs_packet_merge. - Rename lro bit in mlx5_ifc_modify_tir_bitmask_bits to packet_merge. - Rename lro_en in mlx5e_params to packet_merge_type type and combine packet_merge params into one struct mlx5e_packet_merge_param.
Signed-off-by: Khalid Manaa <khalidm@nvidia.com> Signed-off-by: Ben Ben-Ishay <benishay@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
248d3b4c |
| 16-Aug-2021 |
Tariq Toukan <tariqt@nvidia.com> |
net/mlx5e: Support flow classification into RSS contexts
Extend the existing flow classification support, to steer flows not only directly to a receive ring, but also into the new RSS contexts.
Cre
net/mlx5e: Support flow classification into RSS contexts
Extend the existing flow classification support, to steer flows not only directly to a receive ring, but also into the new RSS contexts.
Create needed TIR objects on demand, and hold reference on the RSS context.
Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
f01cc58c |
| 16-Aug-2021 |
Tariq Toukan <tariqt@nvidia.com> |
net/mlx5e: Support multiple RSS contexts
Add support to multiple RSS contexts. Resources of the non-default RSS contexts are allocated and created on demand. Each RSS context can be controlled and c
net/mlx5e: Support multiple RSS contexts
Add support to multiple RSS contexts. Resources of the non-default RSS contexts are allocated and created on demand. Each RSS context can be controlled and configured separately, via the implemented ethtool ops. Here we limit the num of total contexts to 16.
We do not enforce any kind of new limitation over the indirection table content. More specifically, two separate contexts can be configured to fully or partially point to the same set of receive rings.
The default RSS context (index 0) is created with its full set of TIRs. All other contexts are created with an empty set, then TIRs are added upon first usage when steering rules are added. We use a reference counting mechanism to make sure an RSS context is not removed before the rules pointing to it.
Block ethtool set_channels operations when multiple RSS contexts exist, as currently the kernel doesn't protect against inconsistent channels configs that break non-default RSS contexts.
Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
25307a91 |
| 16-Aug-2021 |
Tariq Toukan <tariqt@nvidia.com> |
net/mlx5e: Convert RSS to a dedicated object
Code related to RSS is now encapsulated into a dedicated object and put into new files en/rss.{c,h}. All usages are converted.
Signed-off-by: Tariq Touk
net/mlx5e: Convert RSS to a dedicated object
Code related to RSS is now encapsulated into a dedicated object and put into new files en/rss.{c,h}. All usages are converted.
Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
713ba5e5 |
| 15-Aug-2021 |
Tariq Toukan <tariqt@nvidia.com> |
net/mlx5e: Introduce abstraction of RSS context
Bring all fields that define and maintain RSS behavior together into a new structure. Align all usages with this new structure. Keep it hidden within
net/mlx5e: Introduce abstraction of RSS context
Bring all fields that define and maintain RSS behavior together into a new structure. Align all usages with this new structure. Keep it hidden within rx_res.c. This helps supporting multiple RSS contexts in downstream patch.
Use dynamic allocations for the RSS context.
Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
d443c6f6 |
| 02-Jul-2021 |
Maor Gottlieb <maorg@nvidia.com> |
net/mlx5e: Rename traffic type enums
Rename traffic type enums as part of the preparation for moving the traffic type logic to a separate file.
Signed-off-by: Maor Gottlieb <maorg@nvidia.com> Revie
net/mlx5e: Rename traffic type enums
Rename traffic type enums as part of the preparation for moving the traffic type logic to a separate file.
Signed-off-by: Maor Gottlieb <maorg@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
Revision tags: v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30 |
|
#
3ac90dec |
| 12-Apr-2021 |
Maxim Mikityanskiy <maximmi@nvidia.com> |
net/mlx5e: Allocate the array of channels according to the real max_nch
The channels array in struct mlx5e_rx_res is converted to a dynamic one, which will use the dynamic value of max_nch instead o
net/mlx5e: Allocate the array of channels according to the real max_nch
The channels array in struct mlx5e_rx_res is converted to a dynamic one, which will use the dynamic value of max_nch instead of implementation-defined maximum of MLX5E_MAX_NUM_CHANNELS.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
43ec0f41 |
| 09-Apr-2021 |
Maxim Mikityanskiy <maximmi@nvidia.com> |
net/mlx5e: Hide all implementation details of mlx5e_rx_res
This commit moves all implementation details of struct mlx5e_rx_res under en/rx_res.c. All access to RX resources is now done using methods
net/mlx5e: Hide all implementation details of mlx5e_rx_res
This commit moves all implementation details of struct mlx5e_rx_res under en/rx_res.c. All access to RX resources is now done using methods. Encapsulating RX resources into an object allows for better manageability, because all the implementation details are now in a single place, and external code can use only a limited set of API methods to init/teardown the whole thing, reconfigure RSS and LRO parameters, connect TIRs to flow steering and activate/deactivate TIRs.
mlx5e_rx_res is self-contained and doesn't depend on struct mlx5e_priv or include en.h.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
65d6b6e5 |
| 07-Apr-2021 |
Maxim Mikityanskiy <maximmi@nvidia.com> |
net/mlx5e: Move management of indir traffic types to rx_res
This commit moves the responsibility of keeping the RSS configuration for different traffic types to en/rx_res.{c,h}, hiding the implement
net/mlx5e: Move management of indir traffic types to rx_res
This commit moves the responsibility of keeping the RSS configuration for different traffic types to en/rx_res.{c,h}, hiding the implementation details behind the new getters, and abandons all usage of struct mlx5e_tirc_config, which is no longer useful and superseded by struct mlx5e_rss_params_traffic_type.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
a6696735 |
| 06-Apr-2021 |
Maxim Mikityanskiy <maximmi@nvidia.com> |
net/mlx5e: Convert TIR to a dedicated object
Code related to TIR is now encapsulated into a dedicated object and put into new files en/tir.{c,h}. All usages are converted.
The Builder pattern is us
net/mlx5e: Convert TIR to a dedicated object
Code related to TIR is now encapsulated into a dedicated object and put into new files en/tir.{c,h}. All usages are converted.
The Builder pattern is used to initialize a TIR. It allows to create a multitude of different configurations, turning on and off some specific features in different combinations, without having long parameter lists, initializers per usage and repeating code in initializers.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
6fe5ff2c |
| 06-Apr-2021 |
Maxim Mikityanskiy <maximmi@nvidia.com> |
net/mlx5e: Create struct mlx5e_rss_params_hash
This commit introduces a new struct to store RSS hash parameters: hash function and hash key. The existing usages are changed to use the new struct.
S
net/mlx5e: Create struct mlx5e_rss_params_hash
This commit introduces a new struct to store RSS hash parameters: hash function and hash key. The existing usages are changed to use the new struct.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
0570c1c9 |
| 05-Apr-2021 |
Maxim Mikityanskiy <maximmi@nvidia.com> |
net/mlx5e: Take RQT out of TIR and group RX resources
RQT is not part of TIR, as multiple TIRs may point to the same RQT, as it happens with indir_tir and inner_indir_tir. These instances of a TIR d
net/mlx5e: Take RQT out of TIR and group RX resources
RQT is not part of TIR, as multiple TIRs may point to the same RQT, as it happens with indir_tir and inner_indir_tir. These instances of a TIR don't use the embedded RQT.
This commit takes RQT out of TIR, making them independent. The RQTs are placed into struct mlx5e_rx_res, and items in that struct are regrouped by functionality: RSS, channels and PTP.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
3f22d6c7 |
| 05-Apr-2021 |
Maxim Mikityanskiy <maximmi@nvidia.com> |
net/mlx5e: Move RX resources to a separate struct
This commit moves RQTs and TIRs to a separate struct that is allocated dynamically in profiles that support these RX resources (all profiles, except
net/mlx5e: Move RX resources to a separate struct
This commit moves RQTs and TIRs to a separate struct that is allocated dynamically in profiles that support these RX resources (all profiles, except IPoIB PKey). It also allows to remove rqt_enabled flags, as RQTs are always enabled in profiles that support RX resources.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|