V8 send1 #14

kubalewski · 2023-06-07T21:37:31Z

No description provided.

Add documentation explaining common netlink interface to configure DPLL devices and monitoring events. Common way to implement DPLL device in a driver is also covered. v7 -> v8: - fix DPLL_MODE_MANUAL documentation - remove DPLL_MODE_NCO - remove DPLL_LOCK_STATUS_CALIBRATING - add grepability Use full names of commands, attributes and values of dpll subsystem in the documentation - align documentation with changes introduced in v8 - fix typos - fix phrases to better show the intentions - move dpll.rst to Documentation/driver-api/ Signed-off-by: Vadim Fedorenko <[email protected]> Signed-off-by: Arkadiusz Kubalewski <[email protected]>

Add a protocol spec for DPLL. Add code generated from the spec. v7 -> v8: - remove unspec attribute values - add 10 KHZ and 77,5 KHZ frequency defines - fix documentation - remove assigned values from subset attributes - reorder dpll attributes - fix `device` nested attribute usage, device get is not used on pin-get - temperature with 3 digit float precision - remove enum from subset definitions - move pin-direction to pin-dpll tuple/subset - remove DPLL_MODE_NCO - remove DPLL_LOCK_STATUS_CALIBRATING - fix naming scheme od notification interface functions - separate notifications for pins - rename attribute enum name: dplla -> dpll_a - rename pin-idx to pin-id - remove attributes: pin-parent-idx, device - replace bus-name and dev-name attributes with module-name - replace pin-label with 3 new attributes: pin-board-label, pin-panel-label, pin-package-label - add device-id-get and pin-id-get commands - remove rclk-dev-name atribute - rename source to input Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Michal Michalik <[email protected]> Signed-off-by: Vadim Fedorenko <[email protected]> Signed-off-by: Arkadiusz Kubalewski <[email protected]>

DPLL framework is used to represent and configure DPLL devices in systems. Each device that has DPLL and can configure sources and outputs can use this framework. Netlink interface is used to provide configuration data and to receive notification messages about changes in the configuration or status of DPLL device. Inputs and outputs of the DPLL device are represented as special objects which could be dynamically added to and removed from DPLL device. v7 -> v8: - remove unspec attributes after removing from dpll netlink spec - move pin-direction to pin-dpll tuple - pass parent_priv on state_on_pin_<get/set> - align with new notification definitions from netlink spec - use separated notifications for dpll pins and devices - format notification messages as corresponding get netlink commands - rename pin-idx to pin-id - remove attributes pin-parent-idx, device - use DPLL_A_PIN_PARENT to hold information on parent pin or dpll device - refactor lookup for pins and dplls for dpll subsystem - replace bus-name, dev-name with module-name - replace pin-label with 3 new attributes: pin-board-label, pin-panel-label, pin-package-label - add device-id-get and pin-id-get commands - rename dpll_xa_lock to dpll_lock - improve doxygen in dpll_core.c - remove unused parent and dev fields from dpll_device struct - use u32 for pin_idx in dpll_pin_alloc - use driver provided pin properties struct - verify pin/dpll owner on registering pin - remove const arg modifier for helper _priv functions - remove function declaration _get_by_name() - update SPDX headers - parse netlink set attributes with nlattr array - remove rclk-dev-name attribute - remove redundant doxygen from dpll header - use module_name() to get name of module - add missing/remove outdated kdocs - fix call frequency_set only if available - fix call direction_set only for pin-dpll tuple Co-developed-by: Milena Olech <[email protected]> Signed-off-by: Milena Olech <[email protected]> Co-developed-by: Michal Michalik <[email protected]> Signed-off-by: Michal Michalik <[email protected]> Signed-off-by: Vadim Fedorenko <[email protected]> Co-developed-by: Arkadiusz Kubalewski <[email protected]> Signed-off-by: Arkadiusz Kubalewski <[email protected]>

In case netdevice represents a SyncE port, the user needs to understand the connection between netdevice and associated DPLL pin. There might me multiple netdevices pointing to the same pin, in case of VF/SF implementation. Add a IFLA Netlink attribute to nest the DPLL pin handle, similar to how it is implemented for devlink port. Add a struct dpll_pin pointer to netdev and protect access to it by RTNL. Expose netdev_dpll_pin_set() and netdev_dpll_pin_clear() helpers to the drivers so they can set/clear the DPLL pin relationship to netdev. Note that during the lifetime of struct dpll_pin the pin handle does not change. Therefore it is save to access it lockless. It is drivers responsibility to call netdev_dpll_pin_clear() before dpll_pin_put(). RFCv7->RFCv8: - rebased on top of v8 changes - use dpll_msg_add_pin_handle() in dpll_pin_find_from_nlattr() and dpll_msg_add_pin_parents() - fixed handle to use DPLL_A_PIN_ID and removed temporary comments - added documentation record for dpll_pin pointer - fixed compilation of net/core/dev.c when CONFIG_DPLL is not enabled - adjusted patch description a bit Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: Arkadiusz Kubalewski <[email protected]>

Add firmware admin command to access clock generation unit configuration, it is required to enable Extended PTP and SyncE features in the driver. Add definitions of possible hardware variations of input and output pins related to clock generation unit and functions to access the data. v7 -> v8: - Remove unspec attributes after removing from dpll netlink spec. Signed-off-by: Arkadiusz Kubalewski <[email protected]>

Control over clock generation unit is required for further development of Synchronous Ethernet feature. Interface provides ability to obtain current state of a dpll, its sources and outputs which are pins, and allows their configuration. v7 -> v8: - remove unspec attributes - do not store pin flags received in set commands - use pin state field to provide pin state to the caller - remove include of uapi header - remove redundant check against null arguments - propagate lock function return value to the caller - use switch case instead of if statements - fix dev_dbg to dev_err for error cases - fix dpll/pin lookup on dpll subsytem callbacks - fix extack of dpll subsystem callbacks - remove double negation and variable cast - simplify ice_dpll_pin_state_set function - pass parent_priv on state_on_pin_<get/set> - remove parent hw_idx lookup - fix use const qualifier for dpll/dpll_pin ops - fix IS_ERR macros usage in ice_dpll - add notify previous source state change - fix mutex locking on releasing pins - use '|=' instead of '+=' when modifing capabilities field - rename ice_dpll_register_pins function - clock_id function to return clock ID on the stack instead of using an output variable - DPLL_LOCK_STATUS_CALIBRATING was removed, return: DPLL_LOCK_STATUS_LOCKED - if dpll was locked DPLL_LOCK_STATUS_LOCKED_HO_ACQ - if dpll was locked and holdover is acquired - propagate and use dpll_priv to obtain pf pointer in corresponding functions. - remove null check for pf pointer - adapt to `dpll: core: fix notification scheme` - expose pf related pin to corresponding netdevice - fix dpll init error path - fix dpll pins naming scheme `source` -> `input` - replace pin-label with pin-board-label - dpll remove parent and dev fields from dpll_device - remove rclk-dev-name attribute Co-developed-by: Milena Olech <[email protected]> Signed-off-by: Milena Olech <[email protected]> Co-developed-by: Michal Michalik <[email protected]> Signed-off-by: Michal Michalik <[email protected]> Signed-off-by: Arkadiusz Kubalewski <[email protected]>

Implement basic DPLL operations in ptp_ocp driver as the simplest example of using new subsystem. v7 -> v8: - replace pin-label with pin-board-label - dpll remove parent and dev fields from dpll_device - remove rclk-dev-name attribute - rename source to input Signed-off-by: Vadim Fedorenko <[email protected]> Signed-off-by: Arkadiusz Kubalewski <[email protected]>

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. RFCv7->RFCv8: - rebased on top of v8 changes: - changed notification scheme - no need to fill pin label - implemented locked_ho_acq status - rename DPLL_PIN_DIRECTION_SOURCE -> DPLL_PIN_DIRECTION_INPUT - remove device pointer from dpll_pin_register/dpll_device_register - fixed MSEES register writes - adjusted pin state and lock state values reported - fixed a white space issue Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: Arkadiusz Kubalewski <[email protected]>

Currently, the per cpu upcall counters are allocated after the vport is created and inserted into the system. This could lead to the datapath accessing the counters before they are allocated resulting in a kernel Oops. Here is an example: PID: 59693 TASK: ffff0005f4f51500 CPU: 0 COMMAND: "ovs-vswitchd" #0 [ffff80000a39b5b0] __switch_to at ffffb70f0629f2f4 #1 [ffff80000a39b5d0] __schedule at ffffb70f0629f5cc #2 [ffff80000a39b650] preempt_schedule_common at ffffb70f0629fa60 #3 [ffff80000a39b670] dynamic_might_resched at ffffb70f0629fb58 #4 [ffff80000a39b680] mutex_lock_killable at ffffb70f062a1388 #5 [ffff80000a39b6a0] pcpu_alloc at ffffb70f0594460c #6 [ffff80000a39b750] __alloc_percpu_gfp at ffffb70f05944e68 #7 [ffff80000a39b760] ovs_vport_cmd_new at ffffb70ee6961b90 [openvswitch] ... PID: 58682 TASK: ffff0005b2f0bf00 CPU: 0 COMMAND: "kworker/0:3" #0 [ffff80000a5d2f40] machine_kexec at ffffb70f056a0758 #1 [ffff80000a5d2f70] __crash_kexec at ffffb70f057e2994 #2 [ffff80000a5d3100] crash_kexec at ffffb70f057e2ad8 #3 [ffff80000a5d3120] die at ffffb70f0628234c #4 [ffff80000a5d31e0] die_kernel_fault at ffffb70f062828a8 #5 [ffff80000a5d3210] __do_kernel_fault at ffffb70f056a31f4 #6 [ffff80000a5d3240] do_bad_area at ffffb70f056a32a4 #7 [ffff80000a5d3260] do_translation_fault at ffffb70f062a9710 #8 [ffff80000a5d3270] do_mem_abort at ffffb70f056a2f74 #9 [ffff80000a5d32a0] el1_abort at ffffb70f06297dac #10 [ffff80000a5d32d0] el1h_64_sync_handler at ffffb70f06299b24 #11 [ffff80000a5d3410] el1h_64_sync at ffffb70f056812dc #12 [ffff80000a5d3430] ovs_dp_upcall at ffffb70ee6963c84 [openvswitch] #13 [ffff80000a5d3470] ovs_dp_process_packet at ffffb70ee6963fdc [openvswitch] #14 [ffff80000a5d34f0] ovs_vport_receive at ffffb70ee6972c78 [openvswitch] #15 [ffff80000a5d36f0] netdev_port_receive at ffffb70ee6973948 [openvswitch] #16 [ffff80000a5d3720] netdev_frame_hook at ffffb70ee6973a28 [openvswitch] #17 [ffff80000a5d3730] __netif_receive_skb_core.constprop.0 at ffffb70f06079f90 We moved the per cpu upcall counter allocation to the existing vport alloc and free functions to solve this. Fixes: 95637d9 ("net: openvswitch: release vport resources on failure") Fixes: 1933ea3 ("net: openvswitch: Add support to count upcall packets") Signed-off-by: Eelco Chaudron <[email protected]> Reviewed-by: Simon Horman <[email protected]> Acked-by: Aaron Conole <[email protected]> Signed-off-by: David S. Miller <[email protected]>

Petr Machata says: ==================== mlxsw: Permit enslavement to netdevices with uppers The mlxsw driver currently makes the assumption that the user applies configuration in a bottom-up manner. Thus netdevices need to be added to the bridge before IP addresses are configured on that bridge or SVI added on top of it. Enslaving a netdevice to another netdevice that already has uppers is in fact forbidden by mlxsw for this reason. Despite this safety, it is rather easy to get into situations where the offloaded configuration is just plain wrong. As an example, take a front panel port, configure an IP address: it gets a RIF. Now enslave the port to the bridge, and the RIF is gone. Remove the port from the bridge again, but the RIF never comes back. There is a number of similar situations, where changing the configuration there and back utterly breaks the offload. Similarly, detaching a front panel port from a configured topology means unoffloading of this whole topology -- VLAN uppers, next hops, etc. Attaching the port back is then not permitted at all. If it were, it would not result in a working configuration, because much of mlxsw is written to react to changes in immediate configuration. There is nothing that would go visit netdevices in the attached-to topology and offload existing routes and VLAN memberships, for example. In this patchset, introduce a number of replays to be invoked so that this sort of post-hoc offload is supported. Then remove the vetoes that disallowed enslavement of front panel ports to other netdevices with uppers. The patchset progresses as follows: - In patch #1, fix an issue in the bridge driver. To my knowledge, the issue could not have resulted in a buggy behavior previously, and thus is packaged with this patchset instead of being sent separately to net. - In patch #2, add a new helper to the switchdev code. - In patch #3, drop mlxsw selftests that will not be relevant after this patchset anymore. - Patches #4, #5, #6, #7 and #8 prepare the codebase for smoother introduction of the rest of the code. - Patches #9, #10, #11, #12, #13 and #14 replay various aspects of upper configuration when a front panel port is introduced into a topology. Individual patches take care of bridge and LAG RIF memberships, switchdev replay, nexthop and neighbors replay, and MACVLAN offload. - Patches #15 and #16 introduce RIFs for newly-relevant netdevices when a front panel port is enslaved (in which case all uppers are newly relevant), or, respectively, deslaved (in which case the newly-relevant netdevice is the one being deslaved). - Up until this point, the introduced scaffolding was not really used, because mlxsw still forbids enslavement of mlxsw netdevices to uppers with uppers. In patch #17, this condition is finally relaxed. A sizable selftest suite is available to test all this new code. That will be sent in a separate patchset. ==================== Signed-off-by: David S. Miller <[email protected]>

The cited commit holds encap tbl lock unconditionally when setting up dests. But it may cause the following deadlock: PID: 1063722 TASK: ffffa062ca5d0000 CPU: 13 COMMAND: "handler8" #0 [ffffb14de05b7368] __schedule at ffffffffa1d5aa91 #1 [ffffb14de05b7410] schedule at ffffffffa1d5afdb #2 [ffffb14de05b7430] schedule_preempt_disabled at ffffffffa1d5b528 #3 [ffffb14de05b7440] __mutex_lock at ffffffffa1d5d6cb #4 [ffffb14de05b74e8] mutex_lock_nested at ffffffffa1d5ddeb #5 [ffffb14de05b74f8] mlx5e_tc_tun_encap_dests_set at ffffffffc12f2096 [mlx5_core] #6 [ffffb14de05b7568] post_process_attr at ffffffffc12d9fc5 [mlx5_core] #7 [ffffb14de05b75a0] mlx5e_tc_add_fdb_flow at ffffffffc12de877 [mlx5_core] #8 [ffffb14de05b75f0] __mlx5e_add_fdb_flow at ffffffffc12e0eef [mlx5_core] #9 [ffffb14de05b7660] mlx5e_tc_add_flow at ffffffffc12e12f7 [mlx5_core] #10 [ffffb14de05b76b8] mlx5e_configure_flower at ffffffffc12e1686 [mlx5_core] #11 [ffffb14de05b7720] mlx5e_rep_indr_offload at ffffffffc12e3817 [mlx5_core] #12 [ffffb14de05b7730] mlx5e_rep_indr_setup_tc_cb at ffffffffc12e388a [mlx5_core] #13 [ffffb14de05b7740] tc_setup_cb_add at ffffffffa1ab2ba8 #14 [ffffb14de05b77a0] fl_hw_replace_filter at ffffffffc0bdec2f [cls_flower] #15 [ffffb14de05b7868] fl_change at ffffffffc0be6caa [cls_flower] #16 [ffffb14de05b7908] tc_new_tfilter at ffffffffa1ab71f0 [1031218.028143] wait_for_completion+0x24/0x30 [1031218.028589] mlx5e_update_route_decap_flows+0x9a/0x1e0 [mlx5_core] [1031218.029256] mlx5e_tc_fib_event_work+0x1ad/0x300 [mlx5_core] [1031218.029885] process_one_work+0x24e/0x510 Actually no need to hold encap tbl lock if there is no encap action. Fix it by checking if encap action exists or not before holding encap tbl lock. Fixes: 37c3b9f ("net/mlx5e: Prevent encap offload when neigh update is running") Signed-off-by: Chris Mi <[email protected]> Reviewed-by: Vlad Buslov <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>

Vadim Fedorenko and others added 8 commits June 8, 2023 21:11

kubalewski force-pushed the v8_send1 branch from de2bea8 to 0216a3d Compare June 8, 2023 19:20

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

V8 send1 #14

V8 send1 #14

kubalewski commented Jun 7, 2023

V8 send1 #14

Are you sure you want to change the base?

V8 send1 #14

Conversation

kubalewski commented Jun 7, 2023