- 04 May, 2022 40 commits
-
-
Ido Schimmel authored
The driver periodically queries the device for activity of ACL rules in order to report it to tc upon 'FLOW_CLS_STATS'. In Spectrum-2 and later ASICs, multicast routes are programmed as ACL rules, but unlike rules installed by tc, their activity is of no interest. Avoid unnecessary activity query for such rules by always reporting them as inactive. Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Petr Machata authored
When trapping packets for on-CPU processing, Spectrum machines differentiate between control and non-control traps. Traffic trapped through non-control traps is treated as data and kept in shared buffer in pools 0-4. Traffic trapped through control traps is kept in the dedicated control buffer 9. The advantage of marking traps as control is that pressure in the data plane does not prevent the control traffic to be processed. When the LLDP trap was introduced, it was marked as a control trap. But then in commit aed4b572 ("mlxsw: spectrum: PTP: Hook into packet receive path"), PTP traps were introduced. Because Ethernet-encapsulated PTP packets look to the Spectrum-1 ASIC as LLDP traffic and are trapped under the LLDP trap, this trap was reconfigured as non-control, in sync with the PTP traps. There is however no requirement that PTP traffic be handled as data. Besides, the usual encapsulation for PTP traffic is UDP, not bare Ethernet, and that is in deployments that even need PTP, which is far less common than LLDP. This is reflected by the default policer, which was not bumped up to the 19Kpps / 24Kpps that is the expected load of a PTP-enabled Spectrum-1 switch. Marking of LLDP trap as non-control was therefore probably misguided. In this patch, change it back to control. Reported-by:
Maksym Yaremchuk <maksymy@nvidia.com> Signed-off-by:
-
Petr Machata authored
The idea behind the warnings is that the user would get warned in case when more than one priority is configured for a given DSCP value on a netdevice. The warning is currently wrong, because dcb_ieee_getapp_mask() returns the first matching entry, not all of them, and the warning will then claim that some priority is "current", when in fact it is not. But more importantly, the warning is misleading in general. Consider the following commands: # dcb app flush dev swp19 dscp-prio # dcb app add dev swp19 dscp-prio 24:3 # dcb app replace dev swp19 dscp-prio 24:2 The last command will issue the following warning: mlxsw_spectrum3 0000:07:00.0 swp19: Ignoring new priority 2 for DSCP 24 in favor of current value of 3 The reason is that the "replace" command works by first adding the new value, and then removing all old values. This is the only way to make the replacement without causing the traffic to be prioritized to whatever the chip defaults to. The warning is issued in response to adding the new priority, and then no warning is shown when the old priority is removed. The upshot is that the canonical way to change traffic prioritization always produces a warning about ignoring the new priority, but what gets configured is in fact what the user intended. An option to just emit warning every time that the prioritization changes just to make it clear that it happened is obviously unsatisfactory. Therefore, in this patch, remove the warnings. Reported-by:
-
Petr Machata authored
It is customary for selftests to have a comment with a topology diagram, which serves to illustrate the situation in which the test is done. This selftest lacks it. Add it. Signed-off-by:
-
Petr Machata authored
It is customary for selftests to have a comment with a topology diagram, which serves to illustrate the situation in which the test is done. This selftest lacks it. Add it. While at it, fix the list of tests so that the test names are enumerated one at a line. Signed-off-by:
-
Petr Machata authored
A number of mlxsw-specific QoS tests use manual QoS DCB management. As such, they need to make sure lldpad is not running, because it would override the configuration the test has applied using other tools. To that end, these selftests invoke the bail_on_lldpad() helper, which terminates the selftest if th lldpad is running. Some of these tests however first install the bash exit trap, which invokes a cleanup() at the test exit. If bail_on_lldpad() has terminated the script even before the setup part was run, the cleanup part will be very confused. Therefore make sure bail_on_lldpad() is invoked before the cleanup is registered. While there are still edge cases where the user terminates the script before the setup was fully done, this takes care of a common situation where the cleanup would be invoked in an inconsistent state. Signed-off-by:
-
David S. Miller authored
Martin Habets says: ==================== sfc: Move Siena into a separate subdirectory The Siena NICs (SFN5000 and SFN6000 series) went EOL in November 2021. Most of these adapters have been remove from our test labs, and testing has been reduced to a minimum. This patch series creates a separate kernel module for the Siena architecture, analogous to what was done for Falcon some years ago. This reduces our maintenance for the sfc.ko module, and allows us to enhance the EF10 and EF100 drivers without the risk of breaking Siena NICs. After this series further enhancements are needed to differentiate the new kernel module from sfc.ko, and the Siena code can be removed from sfc.ko. Thes will be posted as a small follow-up series. The Siena module is not built by default, but can be enabled using Kconfig option SFC_SIENA. This will create module sfc-siena.ko. Patches Patch 1 disables the Siena code in the sfc.ko module. Patches 2-6 establish the code base for the Siena driver. Patches 7-12 ensure the allyesconfig build succeeds. Patch 13 adds the basic Siena module. I do not expect patch 2 through 5 to be reviewed, they are FYI only. No checkpatch issues were resolved as part of these, but they were fixed in the subsequent patches. Testing Various build tests were done such as allyesconfig, W=1 and sparse. The new sfc-siena.ko and sfc.ko modules were tested on a machine with both these NICs in them, and several tests were run on both drivers. Martin --- v3: - Fix build errors after rebase. v2: - Split up patch that copies existing files. - Only copy a subset of mcdi_pcol.h. - Use --find-copies-harder as suggested by Benjamin Poirier. - Merge several patches for the allyesconfig build into larger ones. ==================== Signed-off-by: -
Martin Habets authored
For Siena we do not need new messages that were defined for the EF100 architecture. Several debug messages have also been removed. Signed-off-by:
Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by:
-
Martin Habets authored
Disable the build of Siena code until later in this patch series. Prevent sfc.ko from binding to Siena NICs. efx_init_sriov/efx_fini_sriov is only used for Siena. Remove calls to those. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
mlx5-updates-2022-05-03 Leon Romanovsky Says: ===================== Extra IPsec cleanup After FPGA IPsec removal, we can go further and make sure that flow steering logic is aligned to mlx5_core standard together with deep cleaning of whole IPsec path. ===================== Signed-off-by: -
David S. Miller authored
Mat Martineau says: ==================== mptcp: Userspace path manager API Userspace path managers (PMs) make use of generic netlink MPTCP events and commands to control addition and removal of MPTCP subflows on an existing MPTCP connection. The path manager events have already been upstream for a while, and this patch series adds four netlink commands for userspace: * MPTCP_PM_CMD_ANNOUNCE: advertise an address that's available for additional subflow connections. * MPTCP_PM_CMD_REMOVE: revoke an advertisement * MPTCP_PM_CMD_SUBFLOW_CREATE: initiate a new subflow on an existing MPTCP connection * MPTCP_PM_CMD_SUBFLOW_DESTROY: close a subflow on an existing MPTCP connection Userspace path managers, such as mptcpd, can be more easily customized for different devices. The in-kernel path manager remains available to handle server use cases. Patches 1-3 update common path manager code (used by both in-kernel and userspace PMs) Patches 4, 6, and 8 implement the new generic netlink commands. Patches 5, 7, and 9-13 add self test support and test cases for the new path manager commands. ==================== Signed-off-by: -
Kishen Maloor authored
This change adds a selftest script that performs a comprehensive behavioral/functional test of all userspace PM capabilities by exercising all the newly added APIs and changes to support said capabilities. Acked-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Kishen Maloor <kishen.maloor@intel.com> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Kishen Maloor authored
This change updates the "pm_nl_ctl" testing sample with a "listen" option to bind a MPTCP listening socket to the provided addr+port. This option is exercised in testing subflow initiation scenarios in conjunction with userspace path managers where the MPTCP application does not hold an active listener to accept requests for new subflows. Acked-by:
-
Kishen Maloor authored
This change adds to self-testing support for the MPTCP netlink interface by capturing various MPTCP netlink events (and all their metadata) associated with connections, subflows and address announcements. It is used in self-testing scripts that exercise MPTCP netlink commands to precisely validate those operations by examining the dispatched MPTCP netlink events in response to those commands. Acked-by:
-
Kishen Maloor authored
This change updates the "pm_nl_ctl" testing sample with a "dsf" (destroy subflow) option to support the newly added netlink interface command MPTCP_PM_CMD_SUBFLOW_DESTROY over the chosen MPTCP connection. E.g. ./pm_nl_ctl dsf lip 10.0.2.1 lport 44567 rip 10.0.2.2 rport 56789 token 823274047 Acked-by:
-
Kishen Maloor authored
This change updates the "pm_nl_ctl" testing sample with a "csf" (create subflow) option to support the newly added netlink interface command MPTCP_PM_CMD_SUBFLOW_CREATE over the chosen MPTCP connection. E.g. ./pm_nl_ctl csf lip 10.0.2.1 lid 23 rip 10.0.2.2 rport 56789 token 823274047 Acked-by:
-
Florian Westphal authored
This allows userspace to tell kernel to add a new subflow to an existing mptcp connection. Userspace provides the token to identify the mptcp-level connection that needs a change in active subflows and the local and remote addresses of the new or the to-be-removed subflow. MPTCP_PM_CMD_SUBFLOW_CREATE requires the following parameters: { token, { loc_id, family, loc_addr4 | loc_addr6 }, { family, rem_addr4 | rem_addr6, rem_port } MPTCP_PM_CMD_SUBFLOW_DESTROY requires the following parameters: { token, { family, loc_addr4 | loc_addr6, loc_port }, { family, rem_addr4 | rem_addr6, rem_port } Acked-by:Florian Westphal <fw@strlen.de> Signed-off-by:
-
Kishen Maloor authored
This change updates the "pm_nl_ctl" testing sample with a "rem" (remove) option to support the newly added netlink interface command MPTCP_PM_CMD_REMOVE to issue a REMOVE_ADDR signal over the chosen MPTCP connection. E.g. ./pm_nl_ctl rem token 823274047 id 23 Acked-by:
-
Kishen Maloor authored
This change adds a MPTCP netlink command for issuing a REMOVE_ADDR signal for an address over the chosen MPTCP connection from a userspace path manager. The command requires the following parameters: {token, loc_id}. Acked-by: -
Kishen Maloor authored
This change updates the "pm_nl_ctl" testing sample with an "ann" (announce) option to support the newly added netlink interface command MPTCP_PM_CMD_ANNOUNCE to issue ADD_ADDR advertisements over the chosen MPTCP connection. E.g. ./pm_nl_ctl ann 192.168.122.75 token 823274047 id 25 dev enp1s0 Acked-by:
-
Kishen Maloor authored
This change adds a MPTCP netlink interface for issuing ADD_ADDR advertisements over the chosen MPTCP connection from a userspace path manager. The command requires the following parameters: { token, { loc_id, family, daddr4 | daddr6 [, dport] } [, if_idx], flags[signal] }. Acked-by: -
Florian Westphal authored
Next patch will need to parse MPTCP_PM_ATTR_ADDR attributes and fill an mptcp_addr_info structure from a different genl command callback. To avoid copy-paste, split the existing function to a helper that does the common part and then call the helper from the (renamed)mptcp_pm_parse_entry function. Acked-by:
-
Kishen Maloor authored
This change introduces a parallel path in the kernel for retrieving the local id, flags, if_index for an addr entry in the context of an MPTCP connection that's being managed by a userspace PM. The userspace and in-kernel PM modes deviate in their procedures for obtaining this information. Acked-by:
-
Kishen Maloor authored
This change adds an internal function to store/retrieve local addrs announced by userspace PM implementations to/from its kernel context. The function addresses the requirements of three scenarios: 1) ADD_ADDR announcements (which require that a local id be provided), 2) retrieving the local id associated with an address, and also where one may need to be assigned, and 3) reissuance of ADD_ADDRs when there's a successful match of addr/id. The list of all stored local addr entries is held under the MPTCP sock structure. Memory for these entries is allocated from the sock option buffer, so the list of addrs is bounded by optmem_max. The list if not released via REMOVE_ADDR signals is ultimately freed when the sock is destructed. Acked-by:
-
Leon Romanovsky authored
Currently, all released FW versions support only two IPsec object modifiers, and modify_field_select get and set same value with proper bits. However, it is not future compatible, as new FW can have more modifiers and "default" will cause to overwrite not-changed fields. Fix it by setting explicitly fields that need to be overwritten. Fixes: 7ed92f97 ("net/mlx5e: IPsec: Add Connect-X IPsec ESN update offload support") Signed-off-by:
Huy Nguyen <huyn@nvidia.com> Reviewed-by:
Raed Salem <raeds@nvidia.com> Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Leon Romanovsky authored
There is no need to perform extra lookup in order to get already known sec_path that was set a couple of lines above. Simply reuse it. Reviewed-by:
-
Leon Romanovsky authored
Remove everything that is not used or from mlx5_accel_esp_xfrm_attrs, together with change type of spi to store proper type from the beginning. Reviewed-by:
-
Leon Romanovsky authored
mlx5 doesn't allow to configure any AEAD ICV length other than 128, so remove the logic that configures other unsupported values. Reviewed-by:
-
Leon Romanovsky authored
Reduce number of hard-coded IPsec capabilities by making sure that mlx5_ipsec_device_caps() sets only supported bits. As part of this change, remove _ACCEL_ notations from the capabilities names as they represent IPsec-capable device, so it is aligned with MLX5_CAP_IPSEC() macro. And prepare the code to IPsec full offload mode. Reviewed-by:
-
Leon Romanovsky authored
Device that lacks proper IPsec capabilities won't pass mlx5e_ipsec_init() later, so no need to advertise HW netdev offload support for something that isn't going to work anyway. Fixes: 8ad893e5 ("net/mlx5e: Remove dependency in IPsec initialization flows") Reviewed-by:
-
Leon Romanovsky authored
The IPsec FS code was implemented with anti-pattern there failures in create functions left the system with dangling pointers that were cleaned in global routines. The less error prone approach is to make sure that failed function cleans everything internally. As part of this change, we remove the batch of one liners and rewrite get/put functions to remove ambiguity. Reviewed-by:
-
Leon Romanovsky authored
Reuse existing struct to pass parameters instead of open code them. Reviewed-by:
-
Leon Romanovsky authored
SA context logic used multiple structures to store same data over and over. By simplifying the SA context interfaces, we can remove extra structs. Reviewed-by:
-
Leon Romanovsky authored
This change cleanups the mlx5 esp interface. Reviewed-by:
-
Leon Romanovsky authored
The mlx5 IPsec code has logical separation between code that operates with XFRM objects (ipsec.c), HW objects (ipsec_offload.c), flow steering logic (ipsec_fs.c) and data path (ipsec_rxtx.c). Such separation makes sense for C-files, but isn't needed at all for H-files as they are included in batch anyway. Reviewed-by:
-
Leon Romanovsky authored
All callers build xfrm attributes with help of mlx5e_ipsec_build_accel_xfrm_attrs() function that ensure validity of attributes. There is no need to recheck them again. Reviewed-by:
-
Leon Romanovsky authored
mlx5 IPsec code updated ESN through workqueue with allocation calls in the data path, which can be saved easily if the work is created during XFRM state initialization routine. The locking used later in the work didn't protect from anything because change of HW context is possible during XFRM state add or delete only, which can cancel work and make sure that it is not running. Reviewed-by:
-
Leon Romanovsky authored
There is no need in one-liners wrappers to call internal functions. Let's remove them. Reviewed-by:
-
Leon Romanovsky authored
The XFRM code performs fallback to software IPsec if .xdo_dev_state_add() returns -EOPNOTSUPP. This is what mlx5 did very deep in its stack trace, despite have all the knowledge that IPsec is not going to work in very early stage. This is achieved by making sure that priv->ipsec pointer is valid for fully working and supported hardware crypto IPsec engine. In case, the hardware IPsec is not supported, the XFRM code will set NULL to xso->dev and it will prevent from calls to various .xdo_dev_state_*() callbacks. Reviewed-by:
-
Leon Romanovsky authored
Ensure that flow steering is usable as early as possible, to understand if crypto IPsec is supported or not. Reviewed-by:
-
