- 04 May, 2022 10 commits
-
-
Kishen Maloor authored
This change updates the "pm_nl_ctl" testing sample with a "rem" (remove) option to support the newly added netlink interface command MPTCP_PM_CMD_REMOVE to issue a REMOVE_ADDR signal over the chosen MPTCP connection. E.g. ./pm_nl_ctl rem token 823274047 id 23 Acked-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Kishen Maloor <kishen.maloor@intel.com> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Kishen Maloor authored
This change adds a MPTCP netlink command for issuing a REMOVE_ADDR signal for an address over the chosen MPTCP connection from a userspace path manager. The command requires the following parameters: {token, loc_id}. Acked-by: -
Kishen Maloor authored
This change updates the "pm_nl_ctl" testing sample with an "ann" (announce) option to support the newly added netlink interface command MPTCP_PM_CMD_ANNOUNCE to issue ADD_ADDR advertisements over the chosen MPTCP connection. E.g. ./pm_nl_ctl ann 192.168.122.75 token 823274047 id 25 dev enp1s0 Acked-by:
-
Kishen Maloor authored
This change adds a MPTCP netlink interface for issuing ADD_ADDR advertisements over the chosen MPTCP connection from a userspace path manager. The command requires the following parameters: { token, { loc_id, family, daddr4 | daddr6 [, dport] } [, if_idx], flags[signal] }. Acked-by: -
Florian Westphal authored
Next patch will need to parse MPTCP_PM_ATTR_ADDR attributes and fill an mptcp_addr_info structure from a different genl command callback. To avoid copy-paste, split the existing function to a helper that does the common part and then call the helper from the (renamed)mptcp_pm_parse_entry function. Acked-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
Kishen Maloor authored
This change introduces a parallel path in the kernel for retrieving the local id, flags, if_index for an addr entry in the context of an MPTCP connection that's being managed by a userspace PM. The userspace and in-kernel PM modes deviate in their procedures for obtaining this information. Acked-by:
-
Kishen Maloor authored
This change adds an internal function to store/retrieve local addrs announced by userspace PM implementations to/from its kernel context. The function addresses the requirements of three scenarios: 1) ADD_ADDR announcements (which require that a local id be provided), 2) retrieving the local id associated with an address, and also where one may need to be assigned, and 3) reissuance of ADD_ADDRs when there's a successful match of addr/id. The list of all stored local addr entries is held under the MPTCP sock structure. Memory for these entries is allocated from the sock option buffer, so the list of addrs is bounded by optmem_max. The list if not released via REMOVE_ADDR signals is ultimately freed when the sock is destructed. Acked-by:
-
Jakub Kicinski authored
Merge tag 'wireless-next-2022-05-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v5.19 First set of patches for v5.19 and this is a big one. We have two new drivers, a change in mac80211 STA API affecting most drivers and ath11k getting support for WCN6750. And as usual lots of fixes and cleanups all over. Major changes: new drivers - wfx: silicon labs devices - plfxlc: pureLiFi X, XL, XC devices mac80211 - host based BSS color collision detection - prepare sta handling for IEEE 802.11be Multi-Link Operation (MLO) support rtw88 - support TP-Link T2E devices rtw89 - support firmware crash simulation - preparation for 8852ce hardware support ath11k - Wake-on-WLAN support for QCA6390 and WCN6855 - device recovery (firmware restart) support for QCA6390 and WCN6855 - support setting Specific Absorption Rate (SAR) for WCN6855 - read country code from SMBIOS for WCN6855/QCA6390 - support for WCN6750 wcn36xx - support for transmit rate reporting to user space * tag 'wireless-next-2022-05-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (228 commits) rtw89: 8852c: rfk: add DPK rtw89: 8852c: rfk: add IQK rtw89: 8852c: rfk: add RX DCK rtw89: 8852c: rfk: add RCK rtw89: 8852c: rfk: add TSSI rtw89: 8852c: rfk: add LCK rtw89: 8852c: rfk: add DACK rtw89: 8852c: rfk: add RFK tables plfxlc: fix le16_to_cpu warning for beacon_interval rtw88: remove a copy of the NAPI_POLL_WEIGHT define carl9170: tx: fix an incorrect use of list iterator wil6210: use NAPI_POLL_WEIGHT for napi budget ath10k: remove a copy of the NAPI_POLL_WEIGHT define ath11k: Add support for WCN6750 device ath11k: Datapath changes to support WCN6750 ath11k: HAL changes to support WCN6750 ath11k: Add QMI changes for WCN6750 ath11k: Fetch device information via QMI for WCN6750 ath11k: Add register access logic for WCN6750 ath11k: Add HW params for WCN6750 ... ==================== Link: https://lore.kernel.org/r/20220503153622.C1671C385A4@smtp.kernel.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Most drivers should not have to worry about selecting the right weight for their NAPI instances and pass NAPI_POLL_WEIGHT. It'd be best if we didn't require the argument at all and selected the default internally. This change prepares the ground for such reshuffling, allowing for a smooth transition. The following API should remain after the next release cycle: netif_napi_add() netif_napi_add_weight() netif_napi_add_tx() netif_napi_add_tx_weight() Where the _weight() variants take an explicit weight argument. I opted for a _weight() suffix rather than a __ prefix, because we use __ in places to mean that caller needs to also issue a synchronize_net() call. Signed-off-by:
-
Vladimir Oltean authored
Test basic (port-default, VLAN PCP and IP DSCP) QoS classification for Ocelot switches. Advanced QoS classification using tc filters is covered by tc_flower_chains.sh in the same directory. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20220502155424.4098917-1-vladimir.oltean@nxp.comSigned-off-by:
-
- 03 May, 2022 30 commits
-
-
Jakub Kicinski authored
Mat Martineau says: ==================== mptcp: Userspace path manager prerequisites This series builds upon the path manager mode selection changes merged in 4994d4fa ("Merge branch 'mptcp-path-manager-mode-selection'") to further modify the path manager code in preparation for adding the new netlink commands to announce/remove advertised addresses and create/destroy subflows of an MPTCP connection. The third and final patch series for the userspace path manager will implement those commands as discussed in https://lore.kernel.org/netdev/23ff3b49-2563-1874-fa35-3af55d3088e7@linux.intel.com/#r Patches 1, 5, and 7 remove some internal constraints on path managers (in general) without changing in-kernel PM behavior. Patch 2 adds a self test to validate MPTCP address advertisement ack behavior. Patches 3, 4, and 6 add new attributes to existing MPTCP netlink events and track internal state for populating those attributes. ==================== Link: https://lore.kernel.org/r/20220502205237.129297-1-mathew.j.martineau@linux.intel.comSigned-off-by:
-
Kishen Maloor authored
This change allows userspace PM implementations to reissue ADD_ADDR announcements (if necessary) based on their chosen policy. Acked-by:
-
Kishen Maloor authored
This change records the 'server_side' attribute of MPTCP_EVENT_CREATED and MPTCP_EVENT_ESTABLISHED events to inform their recipient about the Client/Server role of the running MPTCP application. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/246Acked-by:
-
Kishen Maloor authored
This change updates internal logic to permit subflows to be established from either the client or server ends of MPTCP connections. This symmetry and added flexibility may be harnessed by PM implementations running on either end in creating new subflows. The essence of this change lies in not relying on the "server_side" flag (which continues to be available if needed). Acked-by:
-
Kishen Maloor authored
Per RFC 8684, if no port is specified in an ADD_ADDR message, MPTCP SHOULD attempt to connect to the specified address on the same port as the port that is already in use by the subflow on which the ADD_ADDR signal was sent. To facilitate that, this change reflects the specific remote port in use by that subflow in MPTCP_EVENT_ANNOUNCED events. Acked-by:
-
Kishen Maloor authored
This change reads the addr id assigned to the remote endpoint of a subflow from the MP_JOIN SYN/ACK message and stores it in the related subflow context. The remote id was not being captured prior to this change, and will now provide a consistent view of remote endpoints and their ids as seen through netlink events. Acked-by:
-
Mat Martineau authored
Check userspace PM behavior to ensure ADD_ADDR echoes are only sent when there is an active userspace daemon. If the daemon is restarting or hasn't loaded yet, the missing echo will cause the peer to retransmit the ADD_ADDR - and hopefully the daemon will be ready to receive it at that later time. Reviewed-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
-
Kishen Maloor authored
Current limits on the # of addresses/subflows must apply only to in-kernel PM managed sockets. Thus this change removes such restrictions on connections overseen by non-kernel (e.g. userspace) PMs. This change also ensures that the kernel does not record stats inside struct mptcp_pm_data updated along kernel code paths when exercised via non-kernel PMs. Additionally, address announcements are acknolwedged and subflow requests are honored only when it's deemed that a userspace path manager is active at the time. Acked-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxPaolo Abeni authored
Saeed Mahameed says: ==================== mlx5-updates-2022-05-02 1) Trivial Misc updates to mlx5 driver 2) From Mark Bloch: Flow steering, general steering refactoring/cleaning An issue with flow steering deletion flow (when creating a rule without dests) turned out to be easy to fix but during the fix some issue with the flow steering creation/deletion flows have been found. The following patch series tries to fix long standing issues with flow steering code and hopefully preventing silly future bugs. A) Fix an issue where a proper dest type wasn't assigned. B) Refactor and fix dests enums values, refactor deletion function and do proper bookkeeping of dests. C) Change mlx5_del_flow_rules() to delete rules when there are no no more rules attached associated with an FTE. D) Don't call hard coded deletion function but use the node's defined one. E) Add a WARN_ON() to catch future bugs when an FTE with dests is deleted. * tag 'mlx5-updates-2022-05-02' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux: net/mlx5: fs, an FTE should have no dests when deleted net/mlx5: fs, call the deletion function of the node net/mlx5: fs, delete the FTE when there are no rules attached to it net/mlx5: fs, do proper bookkeeping for forward destinations net/mlx5: fs, add unused destination type net/mlx5: fs, jump to exit point and don't fall through net/mlx5: fs, refactor software deletion rule net/mlx5: fs, split software and IFC flow destination definitions net/mlx5e: TC, set proper dest type net/mlx5e: Remove unused mlx5e_dcbnl_build_rep_netdev function net/mlx5e: Drop error CQE handling from the XSK RX handler net/mlx5: Print initializing field in case of timeout net/mlx5: Delete redundant default assignment of runtime devlink params net/mlx5: Remove useless kfree net/mlx5: use kvfree() for kvzalloc() in mlx5_ct_fs_smfs_matcher_create ==================== Link: https://lore.kernel.org/r/Signed-off-by: -
Paolo Abeni authored
Ido Schimmel says: ==================== mlxsw: Remove size limitations on egress descriptor buffer Petr says: Spectrum machines have two resources related to keeping packets in an internal buffer: bytes (allocated in cell-sized units) for packet payload, and descriptors, for keeping headers. Currently, mlxsw only configures the bytes part of the resource management. Spectrum switches permit a full parallel configuration for the descriptor resources, including port-pool and port-TC-pool quotas. By default, these are all configured to use pool 14, with an infinite quota. The ingress pool 14 is then infinite in size. However, egress pool 14 has finite size by default. The size is chip dependent, but always much lower than what the chip actually permits. As a result, we can easily construct workloads that exhaust the configured descriptor limit. Going forward, mlxsw will have to fix this issue properly by maintaining descriptor buffer sizes, TC bindings, and quotas that match the architecture recommendation. Short term, fix the issue by configuring the egress descriptor pool to be infinite in size as well. This will maintain the same configuration philosophy, but will unlock all chip resources to be usable. In this patchset, patch #1 first adds the "desc" field into the pool configuration register. Then in patch #2, the new field is used to configure both ingress and egress pool 14 as infinite. In patches #3 and #4, add a selftest that verifies that a large burst can be absorbed by the shared buffer. This test specifically exercises a scenario where descriptor buffer is the limiting factor and the test fails without the above patches. ==================== Link: https://lore.kernel.org/r/20220502084926.365268-1-idosch@nvidia.comSigned-off-by:
-
Petr Machata authored
Add a test that sends 1Gbps of traffic through the switch, into which it then injects a burst of traffic and tests that there are no drops. Signed-off-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
Petr Machata authored
Add two helpers, start_traffic_pktsize() and start_tcp_traffic_pktsize(), that allow explicit overriding of packet size. Change start_traffic() and start_tcp_traffic() to dispatch through these helpers with the default packet size. Signed-off-by:
-
Petr Machata authored
Spectrum machines have two resources related to keeping packets in an internal buffer: bytes (allocated in cell-sized units) for packet payload, and descriptors, for keeping metadata. Currently, mlxsw only configures the bytes part of the resource management. Spectrum switches permit a full parallel configuration for the descriptor resources, including port-pool and port-TC-pool quotas. By default, these are all configured to use pool 14, with an infinite quota. The ingress pool 14 is then infinite in size. However, egress pool 14 has finite size by default. The size is chip dependent, but always much lower than what the chip actually permits. As a result, we can easily construct workloads that exhaust the configured descriptor limit. Fix the issue by configuring the egress descriptor pool to be infinite in size as well. This will maintain the configuration philosophy of the default configuration, but will unlock all chip resources to be usable. In the code, include both the configuration of ingress and ingress, mostly for clarity. Signed-off-by:
-
Petr Machata authored
SBPR, or Shared Buffer Pools Register, configures and retrieves the shared buffer pools and configuration. The desc field determines whether the configuration relates to the byte pool or the descriptor pool. Signed-off-by:
-
Paolo Abeni authored
Tonghao Zhang says: ==================== use standard sysctl macro From: Tonghao Zhang <xiangxia.m.yue@gmail.com> This patchset introduce sysctl macro or replace var with macro. ==================== Link: https://lore.kernel.org/r/20220501035524.91205-1-xiangxia.m.yue@gmail.comSigned-off-by:
-
Tonghao Zhang authored
Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Iurii Zaikin <yzaikin@google.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Cc: David Ahern <dsahern@kernel.org> Cc: Simon Horman <horms@verge.net.au> Cc: Julian Anastasov <ja@ssi.bg> Cc: Pablo Neira Ayuso <pablo@netfilter.org> Cc: Jozsef Kadlecsik <kadlec@netfilter.org> Cc: Florian Westphal <fw@strlen.de> Cc: Shuah Khan <shuah@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Eric Dumazet <edumazet@google.com> Cc: Lorenz Bauer <lmb@cloudflare.com> Cc: Akhmat Karakotov <hmukos@yandex-team.ru> Signed-off-by:
Tonghao Zhang <xiangxia.m.yue@gmail.com> Signed-off-by:
-
Tonghao Zhang authored
This patch introdues the SYSCTL_THREE. KUnit: [00:10:14] ================ sysctl_test (10 subtests) ================= [00:10:14] [PASSED] sysctl_test_api_dointvec_null_tbl_data [00:10:14] [PASSED] sysctl_test_api_dointvec_table_maxlen_unset [00:10:14] [PASSED] sysctl_test_api_dointvec_table_len_is_zero [00:10:14] [PASSED] sysctl_test_api_dointvec_table_read_but_position_set [00:10:14] [PASSED] sysctl_test_dointvec_read_happy_single_positive [00:10:14] [PASSED] sysctl_test_dointvec_read_happy_single_negative [00:10:14] [PASSED] sysctl_test_dointvec_write_happy_single_positive [00:10:14] [PASSED] sysctl_test_dointvec_write_happy_single_negative [00:10:14] [PASSED] sysctl_test_api_dointvec_write_single_less_int_min [00:10:14] [PASSED] sysctl_test_api_dointvec_write_single_greater_int_max [00:10:14] =================== [PASSED] sysctl_test =================== ./run_kselftest.sh -c sysctl ... ok 1 selftests: sysctl: sysctl.sh Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Iurii Zaikin <yzaikin@google.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Cc: David Ahern <dsahern@kernel.org> Cc: Simon Horman <horms@verge.net.au> Cc: Julian Anastasov <ja@ssi.bg> Cc: Pablo Neira Ayuso <pablo@netfilter.org> Cc: Jozsef Kadlecsik <kadlec@netfilter.org> Cc: Florian Westphal <fw@strlen.de> Cc: Shuah Khan <shuah@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Eric Dumazet <edumazet@google.com> Cc: Lorenz Bauer <lmb@cloudflare.com> Cc: Akhmat Karakotov <hmukos@yandex-team.ru> Signed-off-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
-
Tonghao Zhang authored
This patch replace two, four and long_one to SYSCTL_XXX. Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Iurii Zaikin <yzaikin@google.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Cc: David Ahern <dsahern@kernel.org> Cc: Simon Horman <horms@verge.net.au> Cc: Julian Anastasov <ja@ssi.bg> Cc: Pablo Neira Ayuso <pablo@netfilter.org> Cc: Jozsef Kadlecsik <kadlec@netfilter.org> Cc: Florian Westphal <fw@strlen.de> Cc: Shuah Khan <shuah@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Eric Dumazet <edumazet@google.com> Cc: Lorenz Bauer <lmb@cloudflare.com> Cc: Akhmat Karakotov <hmukos@yandex-team.ru> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo authored
ath.git patches for v5.19. Major changes: ath11k * support setting Specific Absorption Rate (SAR) for WCN6855 * read country code from SMBIOS for WCN6855/QCA6390 * support for WCN6750
-
Ping-Ke Shih authored
DPK is short for digital pre-distortion calibration. It can adjusts digital waveform according to PA linear characteristics dynamically to enhance TX EVM. Do this calibration when we are going to run on AP channel. To prevent power offset out of boundary, it monitors thermal and set proper boundary to register. 8852c needs two backup buffers, so we enlarge the array. But, 8852a still needs only one, so it only uses first element (index zero). Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220502235408.15052-9-pkshih@realtek.com
-
Ping-Ke Shih authored
IQ signal calibration is a very important calibration to yield good RF performance. We do this calibration only if we are going to run on AP channel. During scanning phase, without this calibration RF performance is still acceptable because it transmits with low data rate at this phase. Signed-off-by:
-
Ping-Ke Shih authored
RX DCK is receiver DC calibration. Do this calibration when bringing up interface and going to run on AP channel. Signed-off-by:
-
Ping-Ke Shih authored
RCK is synchronize RC calibration. It needs to be triggered only once when interface is going to up. Signed-off-by:
-
Ping-Ke Shih authored
TSSI is transmitter signal strength indication, which is a close-loop hardware circuit to feedback actual transmitting power as a reference for next transmission. When we setup channel to connect an AP, it does full calibration. When switching bands or channels, it needs to reset hardware status to prevent use wrong feedback of previous transmission. To do TX power compensation reflecting current temperature, it loads tables of compensation values into registers according to channel and band group. Signed-off-by:
-
Ping-Ke Shih authored
LCK is short fro LC Tank calibration. Do this calibration once driver loads RF parameters table. Since the characteristic can be changed by temperature, we do this calibration again if difference of thermal value is over a threshold. Signed-off-by:
-
Ping-Ke Shih authored
DACK (digital-to-analog converters calibration) is used to calibrate DAC to output analog signals as expected. Signed-off-by:
-
Ping-Ke Shih authored
These tables are used by RFK (RF calibration) to set parameters. These parameters can trigger certain calibration, or configure/reset settings before and after RF calibrations. Signed-off-by:
-
Srinivasan Raju authored
Fix the following sparse warnings: drivers/net/wireless/purelifi/plfxlc/chip.c:36:31: sparse: expected unsigned short [usertype] beacon_interval drivers/net/wireless/purelifi/plfxlc/chip.c:36:31: sparse: got restricted __le16 [usertype] Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Srinivasan Raju <srini.raju@purelifi.com> Signed-off-by:
-
Mark Bloch authored
When deleting an FTE it should have no dests, which means fte->dests_size should be 0. Add a WARN_ON() to catch bugs where the proper tracking wasn't done. Signed-off-by:
Mark Bloch <mbloch@nvidia.com> Reviewed-by:
Maor Gottlieb <maorg@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Mark Bloch authored
Don't call del_hw_fte() directly, instead use the hardware deletion function set. This is just a small cleanup and doesn't change anything as for an FTE the deletion function is already set to del_hw_fte(). Signed-off-by:
-
