- 28 Apr, 2020 8 commits
-
-
Jakub Kicinski authored
Allow users to build parameterized variants of fixtures. If fixtures want variants, they call FIXTURE_VARIANT() to declare the structure to fill for each variant. Each fixture will be re-run for each of the variants defined by calling FIXTURE_VARIANT_ADD() with the differing parameters initializing the structure. Since tests are being re-run, additional initialization (steps, no_print) is also added. Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Acked-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Now that all tests have a fixture object move from a global list of tests to a list of tests per fixture. Order of tests may change as we will now group and run test fixture by fixture, rather than in declaration order. Signed-off-by:
-
Jakub Kicinski authored
Grouping tests by fixture will allow us to parametrize test runs. Create full objects for fixtures. Add a "global" fixture for tests without a fixture. Signed-off-by:
-
Jakub Kicinski authored
Kees suggest to factor out the list append code to a macro, since following commits need it, which leads to code duplication. Suggested-by:
-
David S. Miller authored
Roopa Prabhu says: ==================== New sysctl to turn off nexthop API compat mode Currently route nexthop API maintains user space compatibility with old route API by default. Dumps and netlink notifications support both new and old API format. In systems which have moved to the new API, this compatibility mode cancels some of the performance benefits provided by the new nexthop API. This patch adds new sysctl nexthop_compat_mode which is on by default but provides the ability to turn off compatibility mode allowing systems to run entirely with the new routing API if they wish to. Old route API behaviour and support is not modified by this sysctl v4: - Use davids note for Documenting the sysctl - test with latest iproute2 and adjust 'pref' v3: - Document new sysctl - move sysctl to use proc_dointvec_minmax with 0 and 1 values - selftest: remove pref medium in ipv6 test v2: - Incorporate David Aherns pointers on covering dumps and nexthop deletes. Also use one ipv4 sysctl to cover both ipv4 and ipv6 (I see it is done that way for many others) - Added a selftest to cover dump and notfications for nexthop api compat mode ==================== Signed-off-by: -
Roopa Prabhu authored
New tests to check route dump and notifications with net.ipv4.nexthop_compat_mode on and off. Signed-off-by:
Roopa Prabhu <roopa@cumulusnetworks.com> Reviewed-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Roopa Prabhu authored
Current route nexthop API maintains user space compatibility with old route API by default. Dumps and netlink notifications support both new and old API format. In systems which have moved to the new API, this compatibility mode cancels some of the performance benefits provided by the new nexthop API. This patch adds new sysctl nexthop_compat_mode which is on by default but provides the ability to turn off compatibility mode allowing systems to run entirely with the new routing API. Old route API behaviour and support is not modified by this sysctl. Uses a single sysctl to cover both ipv4 and ipv6 following other sysctls. Covers dumps and delete notifications as suggested by David Ahern. Signed-off-by:
-
Roopa Prabhu authored
Used in subsequent work to skip route delete notifications on nexthop deletes. Suggested-by:
-
- 27 Apr, 2020 32 commits
-
-
Wei Yongjun authored
In case of error, the function gen_pool_create() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Fixes: 93a76530 ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Heiner Kallweit authored
There's a number of consumer mainboards where the BIOS leaves the PHY in a state that it's reporting an invalid PHY ID. To detect such cases add the PHY ID to the error message if no dedicated PHY driver is found. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
git://git.open-mesh.org/linux-mergeDavid S. Miller authored
Simon Wunderlich says: ==================== This cleanup patchset includes the following patches: - bump version strings, by Simon Wunderlich - fix spelling error, by Sven Eckelmann - drop unneeded types.h include, by Sven Eckelmann - change random number generation to prandom_u32_max(), by Sven Eckelmann - remove unused function batadv_arp_change_timeout(), by Yue Haibing ==================== Signed-off-by: -
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Rework matchall offloading plumbing Jiri says: Currently the matchall and flower are handled by registering separate callbacks in mlxsw. That leads to faulty indication "in_hw_count 2" in filter show command for every inserted flower filter. That happens because matchall callback just blindly returns 0 for it and it is wrongly accounted for as "the offloader". I inspected different ways to fix this problem. The only clean solution is to rework handling of matchall in mlxsw a bit. The driver newely registers one callback for bound block which is called for both matchall and flower filter insertions. On the way, iron out the matchall code a bit, push it into a separate file etc. ==================== Signed-off-by: -
Jiri Pirko authored
Add test for matchall classifier with mirred egress mirror action. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Jiri Pirko authored
Move the code taking case of setup of flow offload into spectrum_flow.c Do small renaming of callbacks on the way. Signed-off-by:
-
Jiri Pirko authored
Currently there are two callbacks registered: one for matchall, one for flower. This causes the user to see "in_hw_count 2" in TC filter dump. Because of this and also as a preparation for future matchall offload for rules equivalent to flower-all-match, move the processing of shared block into matchall.c. Leave only one cb for mlxsw driver per-block. Signed-off-by:
-
Jiri Pirko authored
Currently, only the psample_group is accessed using RCU on RX path. However, it is possible (unlikely) that other sample values get change during RX processing. Fix this by having the port->sample struct accessed as RCU pointer, containing all sample values including psample_group pointer. That avoids extra alloc per-port, copying the values and the race condition described above. Signed-off-by:
-
Jiri Pirko authored
As the replace/destroy is going to be used later on per-block, push the per-port rule addition/deletion into separate functions. Signed-off-by:
-
Jiri Pirko authored
Instead of having it in mirror_entry structure, move it to mall_entry and set it during rule insertion. Signed-off-by:
-
Jiri Pirko authored
In the preparation for future changes, have the mlxsw_sp_mall_port_sample_add() function to accept mall_entry including all needed info originally obtained from cls and act pointers. Signed-off-by:
-
Jiri Pirko authored
In the preparation for future changes, have the mlxsw_sp_mall_port_mirror_add() function to accept mall_entry including the "to_dev" originally obtained from act pointer. Signed-off-by:
-
Jiri Pirko authored
On couple of places in mlxsw_sp_acl_rule_del(), block variable is not used directly as it could be. So do it. Signed-off-by:
-
Jiri Pirko authored
Similar to flower, have matchall related code in a separate file. Do some small renaming on the way (consistent "mall" prefixes, dropped "_tc_", dropped "_port_" where suitable). Signed-off-by:
-
Jiri Pirko authored
The code around flow_block is currently mixed in spectrum_acl.c. However, as it really does not directly relate to ACL part only, push the bits into a separate file. Signed-off-by:
-
Jiri Pirko authored
The acl_block structure is going to be used for non-acl case - matchall offload. So rename it accordingly. Signed-off-by:
-
Jiri Pirko authored
The struct is defined in the header, no need to have the helpers in the c file. Move the helpers to the header. Signed-off-by:
-
David S. Miller authored
Heiner Kallweit says: ==================== r8169: improve chip config handling Series includes two improvements for chip configuration handling. ==================== Signed-off-by: -
Heiner Kallweit authored
Two bits in RxConfig are controlled by the following dev->feature's: - NETIF_F_RXALL - NETIF_F_HW_VLAN_CTAG_RX (since RTL8125) We have to take care that RxConfig gets fully configured in rtl_hw_start() after e.g. resume from hibernation. Therefore: - Factor out setting the feature-controlled RxConfig bits to a new function rtl_set_rx_config_features() that is called from rtl8169_set_features() and rtl_hw_start(). - Don't deal with RX_VLAN_8125 in rtl_init_rxcfg(), it will be set by rtl_set_rx_config_features(). - Don't handle NETIF_F_RXALL in rtl_set_rx_mode(). Signed-off-by:
-
Heiner Kallweit authored
It's sufficient to do the masking once in probe() for clearing unwanted bits that may have been set by the BIOS. Signed-off-by:
-
David S. Miller authored
Horatiu Vultur says: ==================== net: bridge: mrp: Add support for Media Redundancy Protocol(MRP) Media Redundancy Protocol is a data network protocol standardized by International Electrotechnical Commission as IEC 62439-2. It allows rings of Ethernet switches to overcome any single failure with recovery time faster than STP. It is primarily used in Industrial Ethernet applications. Based on the previous RFC[1][2][3][4][5], and patches[6][7][8], the MRP state machine and all the timers were moved to userspace, except for the timers used to generate MRP Test frames. In this way the userspace doesn't know and should not know if the HW or the kernel will generate the MRP Test frames. The following changes were added to the bridge to support the MRP: - the existing netlink interface was extended with MRP support, - allow to detect when a MRP frame was received on a MRP ring port - allow MRP instance to forward/terminate MRP frames - generate MRP Test frames in case the HW doesn't have support for this To be able to offload MRP support to HW, the switchdev API was extend. With these changes the userspace doesn't do the following because already the kernel/HW will do: - doesn't need to forward/terminate MRP frames - doesn't need to generate MRP Test frames - doesn't need to detect when the ring is open/closed. The userspace application that is using the new netlink can be found here[9]. The current implementation both in kernel and userspace supports only 2 roles: MRM - this one is responsible to send MRP_Test and MRP_Topo frames on both ring ports. It needs to process MRP_Test to know if the ring is open or closed. This operation is desired to be offloaded to the HW because it requires to generate and process up to 4000 frames per second. Whenever it detects that the ring is open it sends MRP_Topo frames to notify all MRC about changes in the topology. MRM needs also to process MRP_LinkChange frames, these frames are generated by the MRC. When the ring is open then the state of both ports is to forward frames and when the ring is closed then the secondary port is blocked. MRC - this one is responsible to forward MRP frames between the ring ports. In case one of the ring ports gets a link down or up, then MRC will generate a MRP_LinkChange frames. This node should also process MRP_Topo frames and to clear its FDB when it receives this frame. Userspace Deamon +----------+ Client + | +--------------|-----------------------------------------+ Kernel | + Netlink | + Interrupt | | +--------------|------------------------------|----------+ HW | Switchdev | + | The user interacts using the client (called 'mrp'), the client talks to the deamon (called 'mrp_server'), which talks with the kernel using netlink. The kernel will try to offload the requests to the HW via switchdev API. If this will be accepted then in the future the netlink interface can be expended with multiple attributes which are required by different roles of the MRP. Like Media Redundancy Automanager(MRA), Media Interconnect Manager(MIM) and Media Interconnect Client(MIC). [1] https://www.spinics.net/lists/netdev/msg623647.html [2] https://www.spinics.net/lists/netdev/msg624378.html [3] https://www.spinics.net/lists/netdev/msg627500.html [4] https://www.spinics.net/lists/netdev/msg641005.html [5] https://www.spinics.net/lists/netdev/msg643991.html [6] https://www.spinics.net/lists/netdev/msg645378.html [7] https://www.spinics.net/lists/kernel/msg3484685.html [8] https://www.spinics.net/lists/netdev/msg646202.html [9] https://github.com/microchip-ung/mrp/tree/patch-v9 -v4: - fix comments in br_mrp.c - use skb_header_pointer to get br_mrp_tlv_hdr - fix line over 80 characters -v3: - fix unused variables -v2: - drop patch 4 - add port flag BR_MRP_LOST_CONT; - another fix for bisectability -v1: - fix bisectability issues - in case of errors use extack -RFC v5: - use nla_parse_nested - rework the usage of the rcu in br_mrp - reorder patches - few other small issues raised by Nikolay -RFC v4: - extend existing netlink interface to add mrp support - use rcu locks -RFC v3: - move MRP state machine in userspace - create generic netlink interface for configuring the HW using switchdev API -RFC v2: - extend switchdev API to offload to HW ==================== Signed-off-by: -
Horatiu Vultur authored
It is not possible to have the MRP and STP running at the same time on the bridge, therefore add check when enabling the STP to check if MRP is already enabled. In that case return error. Reviewed-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Horatiu Vultur authored
To integrate MRP into the bridge, the bridge needs to do the following: - detect if the MRP frame was received on MRP ring port in that case it would be processed otherwise just forward it as usual. - enable parsing of MRP - before whenever the bridge was set up, it would set all the ports in forwarding state. Add an extra check to not set ports in forwarding state if the port is an MRP ring port. The reason of this change is that if the MRP instance initially sets the port in blocked state by setting the bridge up it would overwrite this setting. Reviewed-by:
-
Horatiu Vultur authored
Implement netlink interface to configure MRP. The implementation will do sanity checks over the attributes and then eventually call the MRP interface. Signed-off-by:
-
Horatiu Vultur authored
Implement the MRP API. In case the HW can't generate MRP Test frames then the SW will try to generate the frames. In case that also the SW will fail in generating the frames then a error is return to the userspace. The userspace is responsible to generate all the other MRP frames regardless if the test frames are generated by HW or SW. The forwarding/termination of MRP frames is happening in the kernel and is done by the MRP instance. The userspace application doesn't do the forwarding. Signed-off-by:
-
Horatiu Vultur authored
Implement the MRP api for switchdev. These functions will just eventually call the switchdev functions: switchdev_port_obj_add/del and switchdev_port_attr_set. Signed-off-by:
-
Horatiu Vultur authored
Extend switchdev API to add support for MRP. The HW is notified in following cases: SWITCHDEV_OBJ_ID_MRP: This is used when a MRP instance is added/removed from the MRP ring. SWITCHDEV_OBJ_ID_RING_ROLE_MRP: This is used when the role of the node changes. The current supported roles are MRM and MRC. SWITCHDEV_OBJ_ID_RING_TEST_MRP: This is used when to start/stop sending MRP_Test frames on the mrp ring ports. This is called only on nodes that have the role MRM. In case this fails then the SW will generate the frames. SWITCHDEV_OBJ_ID_RING_STATE_STATE: This is used when the ring changes it states to open or closed. This is required to notify HW because the MRP_Test frame contains the field MRP_InState which contains this information. SWITCHDEV_ATTR_ID_MRP_PORT_STATE: This is used when the port's state is changed. It can be in blocking/forwarding mode. SWITCHDEV_ATTR_ID_MRP_PORT_ROLE: This is used when port's role changes. The roles of the port can be primary/secondary. This is required to notify HW because the MRP_Test frame contains the field MRP_PortRole that contains this information. Signed-off-by:
-
Horatiu Vultur authored
Define the MRP interface. This interface is used by the netlink to update the MRP instances and by the MRP to make the calls to switchdev to offload it to HW. It defines an MRP instance 'struct br_mrp' which is a list of MRP instances. Which will be part of the 'struct net_bridge'. Each instance has 2 ring ports, a bridge and an ID. In case the HW can't generate MRP Test frames then the SW will generate those. br_mrp_add - adds a new MRP instance. br_mrp_del - deletes an existing MRP instance. Each instance has an ID(ring_id). br_mrp_set_port_state - changes the port state. The port can be in forwarding state, which means that the frames can pass through or in blocked state which means that the frames can't pass through except MRP frames. This will eventually call the switchdev API to notify the HW. This information is used also by the SW bridge to know how to forward frames in case the HW doesn't have this capability. br_mrp_set_port_role - a port role can be primary or secondary. This information is required to be pushed to HW in case the HW can generate MRP_Test frames. Because the MRP_Test frames contains a file with this information. Otherwise the HW will not be able to generate the frames correctly. br_mrp_set_ring_state - a ring can be in state open or closed. State open means that the mrp port stopped receiving MRP_Test frames, while closed means that the mrp port received MRP_Test frames. Similar with br_mrp_port_role, this information is pushed in HW because the MRP_Test frames contain this information. br_mrp_set_ring_role - a ring can have the following roles MRM or MRC. For the role MRM it is expected that the HW can terminate the MRP frames, notify the SW that it stopped receiving MRP_Test frames and trapp all the other MRP frames. While for MRC mode it is expected that the HW can forward the MRP frames only between the MRP ports and copy MRP_Topology frames to CPU. In case the HW doesn't support a role it needs to return an error code different than -EOPNOTSUPP. br_mrp_start_test - this starts/stops the generation of MRP_Test frames. To stop the generation of frames the interval needs to have a value of 0. In this case the userspace needs to know if the HW supports this or not. Not to have duplicate frames(generated by HW and SW). Because if the HW supports this then the SW will not generate anymore frames and will expect that the HW will notify when it stopped receiving MRP frames using the function br_mrp_port_open. br_mrp_port_open - this function is used by drivers to notify the userspace via a netlink callback that one of the ports stopped receiving MRP_Test frames. This function is called only when the node has the role MRM. It is not supposed to be called from userspace. br_mrp_port_switchdev_add - this corresponds to the function br_mrp_add, and will notify the HW that a MRP instance is added. The function gets as parameter the MRP instance. br_mrp_port_switchdev_del - this corresponds to the function br_mrp_del, and will notify the HW that a MRP instance is removed. The function gets as parameter the ID of the MRP instance that is removed. br_mrp_port_switchdev_set_state - this corresponds to the function br_mrp_set_port_state. It would notify the HW if it should block or not non-MRP frames. br_mrp_port_switchdev_set_port - this corresponds to the function br_mrp_set_port_role. It would set the port role, primary or secondary. br_mrp_switchdev_set_role - this corresponds to the function br_mrp_set_ring_role and would set one of the role MRM or MRC. br_mrp_switchdev_set_ring_state - this corresponds to the function br_mrp_set_ring_state and would set the ring to be open or closed. br_mrp_switchdev_send_ring_test - this corresponds to the function br_mrp_start_test. This will notify the HW to start or stop generating MRP_Test frames. Value 0 for the interval parameter means to stop generating the frames. br_mrp_port_open - this function is used to notify the userspace that the port lost the continuity of MRP Test frames. Reviewed-by:
-
Horatiu Vultur authored
This patch adds a new port attribute, IFLA_BRPORT_MRP_RING_OPEN, which allows to notify the userspace when the port lost the continuite of MRP frames. This attribute is set by kernel whenever the SW or HW detects that the ring is being open or closed. Reviewed-by:
-
Horatiu Vultur authored
To integrate MRP into the bridge, first the bridge needs to be aware of ports that are part of an MRP ring and which rings are on the bridge. Therefore extend bridge interface with the following: - add new flag(BR_MPP_AWARE) to the net bridge ports, this bit will be set when the port is added to an MRP instance. In this way it knows if the frame was received on MRP ring port - add new flag(BR_MRP_LOST_CONT) to the net bridge ports, this bit will be set when the port lost the continuity of MRP Test frames. - add a list of MRP instances Reviewed-by:
-
Horatiu Vultur authored
Add the option BRIDGE_MRP to allow to build in or not MRP support. The default value is N. Reviewed-by:
-
Horatiu Vultur authored
Add new nested netlink attribute to configure the MRP. These attributes are used by the userspace to add/delete/configure MRP instances and by the kernel to notify the userspace when the MRP ring gets open/closed. MRP nested attribute has the following attributes: IFLA_BRIDGE_MRP_INSTANCE - the parameter type is br_mrp_instance which contains the instance id, and the ifindex of the two ports. The ports can't be part of multiple instances. This is used to create/delete MRP instances. IFLA_BRIDGE_MRP_PORT_STATE - the parameter type is u32. Which can be forwarding, blocking or disabled. IFLA_BRIDGE_MRP_PORT_ROLE - the parameter type is br_mrp_port_role which contains the instance id and the role. The role can be primary or secondary. IFLA_BRIDGE_MRP_RING_STATE - the parameter type is br_mrp_ring_state which contains the instance id and the state. The state can be open or closed. IFLA_BRIDGE_MRP_RING_ROLE - the parameter type is br_mrp_ring_role which contains the instance id and the ring role. The role can be MRM or MRC. IFLA_BRIDGE_MRP_START_TEST - the parameter type is br_mrp_start_test which contains the instance id, the interval at which to send the MRP_Test frames, how many test frames can be missed before declaring the ring open and the period which represent for how long to send the test frames. Also add the file include/uapi/linux/mrp_bridge.h which defines all the types used by MRP that are also needed by the userpace. Reviewed-by:
-
