- 24 Feb, 2020 17 commits
-
-
Roman Mashak authored
Signed-off-by:
Roman Mashak <mrv@mojatatu.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
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:Colin Ian King <colin.king@canonical.com> 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 Ahern <dsahern@gmail.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 <jiri@mellanox.com> Signed-off-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 9 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:
-
Saeed Mahameed authored
Introduce mlxfw_{info, err, dbg} macros and make them call corresponding dev_* macros, then convert all instances of pr_* to mlxfw_*. This will allow printing the device name mlxfw is operating on. Signed-off-by: -
Saeed Mahameed authored
Make sure mlxfw_firmware_flash reports a detailed user readable error message in every possible error path, basically every time mlxfw_dev->ops->*() is called and an error is returned, or when image initialization is failed. Signed-off-by:
-
Saeed Mahameed authored
Report unique and standard error codes corresponding to the specific FW flash error. In addition, add a more detailed error messages to netlink. Before: $ devlink dev flash pci/0000:05:00.0 file ... Error: mlxfw: Firmware flash failed. devlink answers: Invalid argument After: $ devlink dev flash pci/0000:05:00.0 file ... Error: mlxfw: Firmware flash failed: pending reset. devlink answers: Device busy Signed-off-by:
-
Saeed Mahameed authored
FW flash status notify is currently implemented via a callback to the caller mlx module, and all it is doing is to call devlink_flash_update_status_notify with the specific module devlink instance. Instead of repeating the whole process for all mlx modules and re-implement the status_notify callback again and again. Just provide the devlink instance as part of mlxfw_dev when calling mlxfw_firmware_flash and let mlxfw do the devlink status updates directly. This will be very useful for adding status notify support to mlx5, as already done in this patch, with a simple one line of just providing the devlink instance to mlxfw_firmware_flash. mlxfw now depends on NET_DEVLINK as all other mlx modules. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller authored
Daniel Borkmann says: ==================== pull-request: bpf-next 2020-02-21 The following pull-request contains BPF updates for your *net-next* tree. We've added 25 non-merge commits during the last 4 day(s) which contain a total of 33 files changed, 2433 insertions(+), 161 deletions(-). The main changes are: 1) Allow for adding TCP listen sockets into sock_map/hash so they can be used with reuseport BPF programs, from Jakub Sitnicki. 2) Add a new bpf_program__set_attach_target() helper for adding libbpf support to specify the tracepoint/function dynamically, from Eelco Chaudron. 3) Add bpf_read_branch_records() BPF helper which helps use cases like profile guided optimizations, from Daniel Xu. 4) Enable bpf_perf_event_read_value() in all tracing programs, from Song Liu. 5) Relax BTF mandatory check if only used for libbpf itself e.g. to process BTF defined maps, from Andrii Nakryiko. 6) Move BPF selftests -mcpu compilation attribute from 'probe' to 'v3' as it has been observed that former fails in envs with low memlock, from Yonghong Song. ==================== Signed-off-by:
-
