- 24 Feb, 2020 22 commits
-
-
Leon Romanovsky authored
The in-kernel code has already unique version, which is based on Linus's tag, update the bond driver to be consistent with that version. Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Colin Ian King authored
The pointer 'client' is being initialized with a value that is never read, it is being updated later on. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a literal string. Fix it. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
David Ahern authored
generic_xdp_tx and xdp_do_generic_redirect are only used by builtin code, so remove the EXPORT_SYMBOL_GPL for them. Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Li RongQing authored
After commit 2690048c ("net: igmp: Allow user-space configuration of igmp unsolicited report interval"), they are not used now Signed-off-by:
Li RongQing <lirongqing@baidu.com> Signed-off-by:
-
Roman Mashak authored
Signed-off-by:
Roman Mashak <mrv@mojatatu.com> Signed-off-by:
-
Heiner Kallweit authored
Only call rtl8169_xmit_frags() if the skb is actually fragmented. This avoid a small overhead for non-fragmented skb's, and it allows to simplify rtl8169_xmit_frags() a little. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Colin Ian King authored
The non-zero check on rc is redundant as a previous non-zero check on rc will always return and the second check is never reached, hence it is redundant and can be removed. Also remove a blank line. Addresses-Coverity: ("Logically dead code") Signed-off-by: -
David Ahern authored
The BUG_ON for NULL tfile is now redundant due to a recently added null check after the rcu_dereference. Remove the BUG_ON. Cc: Jason Wang <jasowang@redhat.com> Signed-off-by:
-
David S. Miller authored
Jiri Pirko says: ==================== mlxsw: Cosmetic fixes This is a set of mainly action/trap related cosmetic fixes. No functional changes. ==================== Signed-off-by: -
Ido Schimmel authored
Since commit f3a52c61 ("mlxsw: pci: Utilize MRSR register to perform FW reset") the driver no longer issues a reset via the PCI BAR, so the offset of the reset bit is unused. Remove it. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Acked-by:
-
Jiri Pirko authored
During packet receive, only the first matching RX listener in rx_listener_list is going to get the packet. So there is no meaning in registering two equal listeners with different privs. Remove priv from equality comparison and disable possibility of doing it. Signed-off-by:
-
Jiri Pirko authored
There are couple of places where block pointer as a function argument can be const. So make those const. Signed-off-by:
-
Jiri Pirko authored
The global arrays are treated as const, they should be const, so make them const. Signed-off-by:
-
Jiri Pirko authored
No need to initialize to false, so remove it. Signed-off-by:
-
Jiri Pirko authored
No need for these two flags to be bool. Covert them to bits of u8. Signed-off-by:
-
Jiri Pirko authored
The dummy name for union is no longer needed, remove it. Signed-off-by:
-
Jiri Pirko authored
Commit 0791051c ("mlxsw: core: Create a generic function to register / unregister traps") moved this field to struct mlxsw_listener, but forgot to remove it from struct mlxsw_rx_listener. Remove the unused field. Signed-off-by:
-
Jiri Pirko authored
No need to initialize a single policer multiple times for each group. So move the initialization to be done from mlxsw_sp_trap_init(), making the function much simpler. Also, rename it so it is with sync with spectrum.c policers initialization. Signed-off-by:
-
Jiri Pirko authored
The Trap / Discard Action action got renamed in PRM, so rename it in the code as well. Signed-off-by:
-
Jiri Pirko authored
No need to have forward declarations for mlxsw_sp_rx_drop_listener() and mlxsw_sp_rx_exception_listener(). Just move them up and avoid it. Signed-off-by:
-
Jiri Pirko authored
When calling mlxsw_sp_rx_listener(), use err variable instead of directly checking func return value. Signed-off-by:
-
- 23 Feb, 2020 14 commits
-
-
Heiner Kallweit authored
These constants are used in one place only, so we can remove them and use the values directly. Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Remove RTNL from route insertion path This patch set removes RTNL from the route insertion path in mlxsw in order to reduce the control plane latency: the time it takes to push routes from user space to the kernel and mlxsw. Up until now mlxsw did not have a lock to protect its shared router data structures and instead relied on RTNL. While this was simple and worked, it resulted in large control plane latencies as RTNL was heavily contended - by both the task receiving the netlink messages from user space and the mlxsw workqueue that programs the routes to the device. By removing RTNL and introducing a new router mutex, this patch set reduces the control plane latency by ~80%. A single mutex is added as inside mlxsw there is not a lot of concurrency. In addition, a more fine-grained locking scheme is much more error-prone. Patches #1-#6 are preparations. They add needed locking in NVE and multicast routing code instead of relying on RTNL Patch #7 introduces the new mutex Patches #8-#12 gradually take the lock in various entry points into the routing code Patch #13 removes RTNL in places where it is no longer required ==================== Signed-off-by: -
Ido Schimmel authored
After introducing the router lock in previous patches and making sure it protects internal router structures, we no longer need to rely on RTNL to serialize access to these structures. Remove RTNL from call sites that no longer require it. Two calls sites that keep taking the lock are mlxsw_sp_router_fibmr_event_work() and mlxsw_sp_inet6addr_event_work(). The first calls into ACL code that still assumes RTNL is taken. The second potentially calls into the FID code that also relies on RTNL. Removing RTNL from these two call sites is the subject of future work. Signed-off-by:
-
Ido Schimmel authored
The routing code exports some helper functions that can be called from other driver modules such as the bridge. These helpers are never called with the router lock already held and therefore need to take it in order to serialize access to shared router structures. Signed-off-by:
-
Ido Schimmel authored
Another entry point into the routing code is from inetaddr listeners. The driver registers listeners to IPv4 and IPv6 inetaddr notification chains in order to understand when a RIF needs to be created or destroyed. Serialize access to shared router structures from these listeners by taking the router lock when processing inetaddr events. Signed-off-by:
-
Ido Schimmel authored
One entry point into the routing code is from the netdev listener block. Some netdev events require access to internal router structures. For example, changing the MTU of a netdev requires looking-up the backing RIF and adjusting its MTU. In order to serialize access to shared router structures, take the router lock when processing netdev events that require access to it. Signed-off-by:
-
Ido Schimmel authored
The dpipe code traverses internal router structures such as neighbours and adjacency entries and dumps them to user space via netlink. Up until now the routing code did not have its own locks and relied on RTNL lock to serialize access. This is going to change with the introduction of the router lock. Take the router lock in the code paths where RTNL lock is currently taken so that the latter could be removed by subsequent patches. Signed-off-by:
-
Ido Schimmel authored
There are several work items in the routing code that currently rely on RTNL lock to guard against concurrent changes. Have these work items acquire the router lock in preparation for the removal for RTNL lock from the routing code. Signed-off-by:
-
Ido Schimmel authored
Introduce a mutex to protect the internal structure of the routing code. A single lock is added instead of a more fine-grained and complicated locking scheme because there is not a lot of concurrency in the routing code. The main motivation is remove the dependence on RTNL lock, which is currently used by both the process pushing routes to the kernel and the workqueue pushing the routes to the underlying device. Signed-off-by:
-
Ido Schimmel authored
When a host route is added, the driver checks if the route needs to be promoted to perform NVE decapsulation based on the current NVE configuration. If so, the index of the decapsulation entry is retrieved and associated with the route. Currently, this information is stored in the NVE module which the router module consults. Since the information is protected under RTNL and since route insertion happens with RTNL held, there is no problem to retrieve the information from the NVE module. However, this is going to change and route insertion will no longer happen under RTNL. Instead, a dedicated lock will be introduced for the router module. Therefore, store this information in the router module and change the router module to consult this copy. The validity of the information is set / cleared whenever an NVE tunnel is initialized / de-initialized. When this happens the NVE module calls into the router module to promote / demote the relevant host route. Signed-off-by:
-
Ido Schimmel authored
The dpipe code accesses internal router data structures and acquires RTNL to protect against their changes. Subsequent patches will remove reliance on RTNL and introduce a dedicated lock to protect router data structures. Publish the router struct to internal users such as the dpipe, so that they could acquire it instead of RTNL. Signed-off-by:
-
Ido Schimmel authored
Protect the per-table multicast route list with a lock and remove RTNL from the delayed work that periodically updates the kernel about packets and bytes statistics from each multicast route. Signed-off-by:
-
Ido Schimmel authored
The multicast table list is traversed from a delayed work that periodically updates the kernel about packets and bytes statistics from each multicast route. The list is currently protected by RTNL, but subsequent patches will remove the driver's dependence on this contended lock. In order to be able to remove dependence on RTNL in the next patch, guard this list with a dedicated mutex. Signed-off-by:
-
Ido Schimmel authored
The driver periodically traverses the linked list of multicast routes and updates the kernel about packets and bytes statistics from each multicast route. These statistics are read from a counter associated with the route when it is written to the device. Currently, multicast routes are published via this linked list before they are associated with a counter. Despite that, it is not possible for the driver to access an invalid counter because the delayed work that reads the statistics and multicast route addition / deletion are mutually exclusive using RTNL. In order to be able to remove RTNL, the list needs to be protected by a dedicated lock, but any route published via the list must have an associated counter, otherwise the driver will access an invalid counter. Solve this by re-ordering the operations during multicast route addition so that the route is only added to the linked list after it was written to the device. Similarly, during deletion the route is first removed from the linked list before its deletion from the device. Signed-off-by:
-
- 21 Feb, 2020 4 commits
-
-
David S. Miller authored
Saeed Mahameed says: ==================== mlxfw: Improve error reporting and FW reactivate support This patchset improves mlxfw error reporting to netlink and to kernel log. V2: - Use proper err codes, EBUSY/EIO instead of EALREADY/EREMOTEIO - Fix typo. From Eran and me. 1) patch #1, Make mlxfw/mlxsw fw flash devlink status notify generic, and enable it for mlx5. 2) patches #2..#5 are improving mlxfw flash error messages by reporting detailed mlxfw FSM error messages to netlink and kernel log. 3) patches #6,7 From Eran: Add FW reactivate flow to mlxfw and mlx5 ==================== Reviewed-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Eran Ben Elisha authored
Add support for fsm reactivate via MIRC (Management Image Re-activation Control) set and query commands. For re-activation flow, driver shall first run MIRC set, and then wait until FW is done (via querying MIRC status). Signed-off-by:
Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Acked-by:
-
Eran Ben Elisha authored
Expose fsm_reactivate callback to the mlxfw_dev_ops struct. FSM reactivate is needed before flashing the new image in order to flush the old flashed but not running firmware image. In case mlxfw_dev do not support the reactivation, this step will be skipped. But if later image flash will fail, a hint will be provided by the extack to advise the user that the failure might be related to it. Signed-off-by:
-
Saeed Mahameed authored
Instead of always calling both mlxfw_err and NL_SET_ERR_MSG_MOD with the same message, use the dedicated macro instead. Signed-off-by:
-
