- 28 Jan, 2021 33 commits
-
-
Aya Levin authored
Introduce mlx5e_trap which includes a dedicated RQ and NAPI for trapped packets. Trap-RQ processes packets that were destined to be dropped, but for debug and visibility sake these packets are trapped and reported to devlink. Trap-RQ connects between the HW and the driver and is not a part of a channel. Open mlx5e_create_rq() and mlx5_core_destroy_rq() as API and add dedicate RQ handlers which report to devlink of trapped packets. Signed-off-by:
Aya Levin <ayal@nvidia.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Aya Levin authored
In order to support RQs outside of channel context, change mlx5e_init_di_list() signature to accept NUMA node instead of cpu. In addition, expose dma info helpers as API. This API will be used for RQ's creation in other files in downstream patches. Signed-off-by:
Moshe Shemesh <moshe@nvidia.com> Reviewed-by:
-
Aya Levin authored
Add flow group to the L2 table to hold the catch-all DMAC rule. Add API which adds/removes DMAC trap rule. This rule catches packets that were destined to be dropped due to no-match with previous DMAC rules. The trap rule steer these packets to the trap tir related to the trap-RQ. Signed-off-by:
-
Aya Levin authored
Add flow group to the VLAN table to hold the catch-all VLAN rule. Add API which adds/removes VLAN trap rule. This rule catches packets that were destined to be dropped due to no-match with previous VLAN rules. The trap rule steer these packets to the trap tir related to the trap-RQ. Signed-off-by:
-
Aya Levin authored
Change steering flow to optimize traffic in promiscuous mode. On demand, add a high priority table containing a catch-all rule. All incoming packets are caught by this rule and steered directly to the TTC table. Prior to this change, packets in promiscuous mode may suffer from up to 4 steering hops before reaching TTC table. In addition, this patch will allow us adding a catch-all rule at the end of MAC table to serve MAC trap, with no impact on promiscuous mode performance. Signed-off-by:
Maor Gottlieb <maorg@nvidia.com> Reviewed-by:
-
Aya Levin authored
In order to allow mlx5 core driver to trigger synchronous operations to its consumers, add a blocking events handler. Add wrappers to blocking_notifier_[call_chain/chain_register/chain_unregister]. Add trap callback for action set and notify about this change. Following patches in the set add a listener for this event. Signed-off-by:
-
Aya Levin authored
Change the naming of events notifier head to clarify that it handles only firmware events. Coming patches in the set, add event notifier for software events. Signed-off-by:
-
Aya Levin authored
Core driver is registered to the devlink traps service, which enables the admin to redeem packets that were destined to be dropped due to a particular reason. Register to DMAC filter, allow visibility of packets that were filtered out by the MAC table. Signed-off-by:
-
Aya Levin authored
Add traps registration to mlx5_core devlink register/unregister flow. This patch registers INGRESS_VLAN_FILTER trap. Signed-off-by:
-
Aya Levin authored
Add devlink traps infra-structure to mlx5 core driver. Add traps list to mlx5_priv and corresponding API: - mlx5_devlink_trap_report() to wrap trap reports to devlink - mlx5_devlink_trap_get_num_active() to decide whether to open/close trap resources. Signed-off-by:
-
Aya Levin authored
Add packet trap that can report packets that were dropped due to destination MAC filtering. Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
-
Andrew Lunn authored
Early generations of the mv88e6xxx did not have the global 2 registers. In order to keep the driver slim, it was decided to make the code for these registers optional. Over time, more generations of switches have been added, always supporting global 2 and adding more and more registers. No effort has been made to keep these additional registers also optional to slim the driver down when used for older generations. Optional global 2 now just gives additional development and maintenance burden for no real gain. Make global 2 support always compiled in. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Tested-by:
-
Jakub Kicinski authored
Merge tag 'mac80211-next-for-net-next-2021-01-27' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== More updates: * many minstrel improvements, including removal of the old minstrel in favour of minstrel_ht * speed improvements on FQ * support for RX decapsulation (header conversion) offload * RTNL reduction: limit RTNL usage in the wireless stack mostly to where really needed (regulatory not yet) to reduce contention on it * tag 'mac80211-next-for-net-next-2021-01-27' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next: (24 commits) mac80211: minstrel_ht: fix regression in the max_prob_rate fix virt_wifi: fix deadlock on RTNL cfg80211: avoid holding the RTNL when calling the driver cfg80211: change netdev registration/unregistration semantics mac80211: minstrel_ht: fix rounding error in throughput calculation mac80211: minstrel_ht: increase stats update interval mac80211: minstrel_ht: fix max probability rate selection mac80211: minstrel_ht: improve sample rate selection mac80211: minstrel_ht: improve ampdu length estimation mac80211: minstrel_ht: remove old ewma based rate average code mac80211: remove legacy minstrel rate control mac80211: minstrel_ht: add support for OFDM rates on non-HT clients mac80211: minstrel_ht: clean up CCK code mac80211: introduce aql_enable node in debugfs cfg80211: Add phyrate conversion support for extended MCS in 60GHz band cfg80211: add VHT rate entries for MCS-10 and MCS-11 mac80211: reduce peer HE MCS/NSS to own capabilities mac80211: remove NSS number of 160MHz if not support 160MHz for HE mac80211_hwsim: add 6GHz channels mac80211: add LDPC encoding to ieee80211_parse_tx_radiotap ... ==================== Link: https://lore.kernel.org/r/20210127210915.135550-1-johannes@sipsolutions.netSigned-off-by:
-
Jakub Kicinski authored
Merge tag 'linux-can-next-for-5.12-20210127' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2021-01-27 The first two patches are by me and fix typos on the CAN gw protocol and the flexcan driver. The next patch is by Vincent Mailhol and targets the CAN driver infrastructure, it exports the function that converts the CAN state into a human readable string. A patch by me, which target the CAN driver infrastructure, too, makes the calculation in can_fd_len2dlc() more readable. A patch by Tom Rix fixes a checkpatch warning in the mcba_usb driver. The next seven patches target the mcp251xfd driver. Su Yanjun's patch replaces several hardcoded assumptions when calling regmap, by using regmap_get_val_bytes(). The remaining patches are by me. First an open coded check is replaced by an existing helper function, then in the TX path the padding for CAN-FD frames is cleaned up. The next two patches clean up the RTR frame handling in the RX and TX path. Then support for len8_dlc is added. The last patch adds BQL support. * tag 'linux-can-next-for-5.12-20210127' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: can: mcp251xfd: add BQL support can: mcp251xfd: add len8_dlc support can: mcp251xfd: mcp251xfd_tx_obj_from_skb(): don't copy data for RTR CAN frames in TX-path can: mcp251xfd: mcp251xfd_hw_rx_obj_to_skb(): don't copy data for RTR CAN frames in RX-path can: mcp251xfd: mcp251xfd_tx_obj_from_skb(): clean up padding of CAN-FD frames can: mcp251xfd: mcp251xfd_start_xmit(): use mcp251xfd_get_tx_free() to check TX is is full can: mcp251xfd: replace sizeof(u32) with val_bytes in regmap can: mcba_usb: remove h from printk format specifier can: length: can_fd_len2dlc(): make legnth calculation readable again can: dev: export can_get_state_str() function can: flexcan: fix typos can: gw: fix typo ==================== Link: https://lore.kernel.org/r/20210127092227.2775573-1-mkl@pengutronix.deSigned-off-by:
-
Hoang Huu Le authored
Remove a duplicate code checking for header size in tipc_msg_create() as it's already being done in tipc_msg_init(). Acked-by:
Jon Maloy <jmaloy@redhat.com> Signed-off-by:
Hoang Huu Le <hoang.h.le@dektech.com.au> Link: https://lore.kernel.org/r/20210127025123.6390-1-hoang.h.le@dektech.com.auSigned-off-by:
-
Jakub Kicinski authored
Nikolay Aleksandrov says: ==================== net: bridge: multicast: per-port EHT hosts limit This set adds a simple configurable per-port EHT tracked hosts limit. Patch 01 adds a default limit of 512 tracked hosts per-port, since the EHT changes are still only in net-next that shouldn't be a problem. Then patch 02 adds the ability to configure and retrieve the hosts limit and to retrieve the current number of tracked hosts per port. Let's be on the safe side and limit the number of tracked hosts by default while allowing the user to increase that limit if needed. ==================== Link: https://lore.kernel.org/r/20210126093533.441338-1-razor@blackwall.orgSigned-off-by:
-
Nikolay Aleksandrov authored
Add two new port attributes which make EHT hosts limit configurable and export the current number of tracked EHT hosts: - IFLA_BRPORT_MCAST_EHT_HOSTS_LIMIT: configure/retrieve current limit - IFLA_BRPORT_MCAST_EHT_HOSTS_CNT: current number of tracked hosts Setting IFLA_BRPORT_MCAST_EHT_HOSTS_LIMIT to 0 is currently not allowed. Note that we have to increase RTNL_SLAVE_MAX_TYPE to 38 minimum, I've increased it to 40 to have space for two more future entries. v2: move br_multicast_eht_set_hosts_limit() to br_multicast_eht.c, no functional change Signed-off-by:Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
-
Nikolay Aleksandrov authored
Add a default limit of 512 for number of tracked EHT hosts per-port. Signed-off-by:
-
Jiapeng Zhong authored
Fix the following coccicheck warnings: ./drivers/net/ethernet/rocker/rocker_ofdpa.c:926:34-36: WARNING !A || A && B is equivalent to !A || B. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Zhong <abaci-bugfix@linux.alibaba.com> Link: https://lore.kernel.org/r/1611648783-3916-1-git-send-email-abaci-bugfix@linux.alibaba.comSigned-off-by:
-
Masahiro Yamada authored
These Kconfig files are included from net/Kconfig, inside the if NET ... endif. Remove 'depends on NET', which we know it is already met. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Link: https://lore.kernel.org/r/20210125232026.106855-1-masahiroy@kernel.orgSigned-off-by:
-
Masahiro Yamada authored
CONFIG_NET_L3_MASTER_DEV is a bool option. Change the ifeq conditional to the standard obj-$(CONFIG_NET_L3_MASTER_DEV) form. Use obj-y in net/l3mdev/Makefile because Kbuild visits this Makefile only when CONFIG_NET_L3_MASTER_DEV=y. Signed-off-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20210125231659.106201-4-masahiroy@kernel.orgSigned-off-by:
-
Masahiro Yamada authored
CONFIG_NET_SWITCHDEV is a bool option. Change the ifeq conditional to the standard obj-$(CONFIG_NET_SWITCHDEV) form. Use obj-y in net/switchdev/Makefile because Kbuild visits this Makefile only when CONFIG_NET_SWITCHDEV=y. Signed-off-by:
-
Masahiro Yamada authored
CONFIG_DCB is a bool option. Change the ifeq conditional to the standard obj-$(CONFIG_DCB) form. Use obj-y in net/dcb/Makefile because Kbuild visits this Makefile only when CONFIG_DCB=y. Signed-off-by:
-
Masahiro Yamada authored
When CONFIG_NET is disabled, nothing under the net/ directory is compiled. Move the CONFIG_NET guard to the top Makefile so the net/ directory is entirely skipped. When Kbuild visits net/Makefile, CONFIG_NET is obvioulsy 'y' because CONFIG_NET is a bool option. Clean up net/Makefile. Signed-off-by:
-
Masahiro Yamada authored
CONFIG_NET is a bool option, and this file is compiled only when CONFIG_NET=y. Remove #ifdef CONFIG_NET, which we know it is always met. Signed-off-by:
-
Jakub Kicinski authored
Mat Martineau says: ==================== MPTCP: IPv4-mapped IPv6 addressing for subflows This patch series from the MPTCP tree adds support for IPv4-mapped IPv6 addressing that was missing when multiple subflows were first implemented. Patches 1 and 2 handle the conversion and comparison of the mapped addresses. Patch 3 contains a minor refactor in the path manager's handling of addresses. Patches 4 and 5 add selftests for the new functionality and adjust the selftest timeout. ==================== Link: https://lore.kernel.org/r/20210125185904.6997-1-mathew.j.martineau@linux.intel.comSigned-off-by:
-
Matthieu Baerts authored
On slow systems with kernel debug settings, we can reach the current timeout when all tests are executed. Likely some tests need be improved to remove some 'sleep' and wait (less) for a specific action. This can also improve stability. Signed-off-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Geliang Tang authored
Here, we make sure we support IPv4-mapped in IPv6 addresses in different contexts: - a v4-mapped address is received by the PM and can be used as v4. - a v4 address is received by the PM and can be used even with a v4 mapped socket. We also make sure we don't try to establish subflows between v4 and v6 addresses, e.g. if a real v6 address ends with a valid v4 address. Co-developed-by:
Geliang Tang <geliangtang@gmail.com> Signed-off-by:
-
Matthieu Baerts authored
To avoid confusions like when working on the previous patch, better to declare and assign this variable only where it is needed. Signed-off-by:
-
Matthieu Baerts authored
On one side, we can allow the creation of subflows between v4 mapped in v6 and v4 addresses. For that we look for v4mapped addresses between the local address we want to select and the remote one. On the other side, we also properly deal with received v4mapped addresses, either announced ones or set via Netlink. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/122Suggested-by:
-
Matthieu Baerts authored
With an IPv4 mapped in v6 socket, we were trying to call inet6_bind() with an IPv4 address resulting in a -EINVAL error because the given addr_len -- size of the address structure -- was too short. We now make sure to use address structures for the same family as the MPTCP socket for both the bind() and the connect(). It means we convert v4 addresses to v4 mapped in v6 or the opposite if needed. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/122Co-developed-by:
-
Heiner Kallweit authored
rtl_wol_enable_rx() is called via the following call chain if WoL is enabled: rtl8169_down() -> rtl_prepare_power_down() -> rtl_wol_enable_rx() Therefore we don't have to call this function here. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/34ce78e2-596c-e2ac-16aa-c550fa624c22@gmail.comSigned-off-by:
-
Di Zhu authored
pktgen create threads for all online cpus and bond these threads to relevant cpu repecivtily. when this thread firstly be woken up, it will compare cpu currently running with the cpu specified at the time of creation and if the two cpus are not equal, BUG_ON() will take effect causing panic on the system. Notice that these threads could be migrated to other cpus before start running because of the cpu hotplug after these threads have created. so the BUG_ON() used here seems unreasonable and we can replace it with WARN_ON() to just printf a warning other than panic the system. Signed-off-by:
Di Zhu <zhudi21@huawei.com> Link: https://lore.kernel.org/r/20210125124229.19334-1-zhudi21@huawei.comSigned-off-by:
-
- 27 Jan, 2021 7 commits
-
-
Felix Fietkau authored
Since mi->max_prob_rate is overwritten after the loop that calls minstrel_ht_set_best_prob_rate, the new best rate needs to be written to *dest Fixes: a7fca4e4 ("mac80211: minstrel_ht: fix max probability rate selection") Signed-off-by:
Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20210126154409.6755-1-nbd@nbd.nameSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Fix a regression where everything in virt_wifi would just hang. This happened due to overlapping changes between commit a05829a7 ("cfg80211: avoid holding the RTNL when calling the driver") which had originally needed to change the locking, but then I introduced commit 2fe8ef10 ("cfg80211: change netdev registration/unregistration semantics") instead. virt_wifi somehow fell through the cracks when I undid all the previous locking changes. Fix it now. Fixes: a05829a7 ("cfg80211: avoid holding the RTNL when calling the driver") Reported-by: syzbot+3d2d5e6cc3fb15c6a0fd@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20210127215941.2d6a97b09784.I4f1fac32f67045171be50931f44d77e150911bee@changeidSigned-off-by:
-
Marc Kleine-Budde authored
This patch adds BQL support to the driver. Support for netdev_xmit_more() will be added in a separate patch series. Link: https://lore.kernel.org/r/20210114153448.1506901-7-mkl@pengutronix.deSigned-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This patch adds support for the Classical CAN raw DLC functionality to send and receive DLC values from 9 ... 15 to the mcp251xfd driver. Link: https://lore.kernel.org/r/20210114153448.1506901-6-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
In Classical CAN there are RTR frames. RTR frames have the RTR bit set, may have a dlc != 0, but contain no data. This patch optimizes the TX-path to not copy any data for RTR frames. Link: https://lore.kernel.org/r/20210114153448.1506901-5-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
In Classical CAN there are RTR frames. RTR frames have the RTR bit set, may have a dlc != 0, but contain no data. This patch changes the RX-path to no copy any data for RTR frames, so that the data field in the CAN frame stays 0x0. Link: https://lore.kernel.org/r/20210114153448.1506901-4-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
CAN-FD frames have only specific frame length (0, 1, 2, 3, 4, 5, 6, 7, 8, 12, 16, 20, 24, 32, 48, 64). A CAN-FD frame provided by user space might not cover the whole CAN-FD frame. To avoid sending garbage over the CAN bus the driver pads the CAN frame with 0x0 (if MCP251XFD_SANITIZE_CAN is activated). This patch cleans up the pad len calculation. Rounding to full u32 brings no benefit, in case of CRC transfers, the hw_tx_obj->data is not aligned to u32 anyway. Link: https://lore.kernel.org/r/20210114153448.1506901-3-mkl@pengutronix.deSigned-off-by:
-
