- 15 Jul, 2024 2 commits
-
-
Vladimir Oltean authored
The driver uses the DPAA_TC_TXQ_NUM and DPAA_ETH_TXQ_NUM macros for TX queue handling, and they depend on CONFIG_NR_CPUS. In generic .config files, these can go to very large (8096 CPUs) values for the systems that DPAA1 is integrated in (1-24 CPUs). We allocate a lot of resources that will never be used. Those are: - system memory - QMan FQIDs as managed by qman_alloc_fqid_range(). This is especially painful since currently, when booting with CONFIG_NR_CPUS=8096, a LS1046A-RDB system will only manage to probe 3 of its 6 interfaces. The rest will run out of FQD ("/reserved-memory/qman-fqd" in the device tree) and fail at the qman_create_fq() stage of the probing process. - netdev queues as alloc_etherdev_mq() argument. The high queue indices are simply hidden from the network stack after the call to netif_set_real_num_tx_queues(). With just a tiny bit more effort, we can replace the NR_CPUS compile-time constant with the num_possible_cpus() run-time constant, and dynamically allocate the egress_fqs[] and conf_fqs[] arrays. Even on a system with a high CONFIG_NR_CPUS, num_possible_cpus() will remain equal to the number of available cores on the SoC. The replacement is as follows: - DPAA_TC_TXQ_NUM -> dpaa_num_txqs_per_tc() - DPAA_ETH_TXQ_NUM -> dpaa_max_num_txqs() Signed-off-by:Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by:
Madalin Bucur <madalin.bucur@oss.nxp.com> Link: https://patch.msgid.link/20240713225336.1746343-3-vladimir.oltean@nxp.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Vladimir Oltean authored
The dpaa-eth driver is written for PowerPC and Arm SoCs which have 1-24 CPUs. It depends on CONFIG_NR_CPUS having a reasonably small value in Kconfig. Otherwise, there are 2 functions which allocate on-stack arrays of NR_CPUS elements, and these can quickly explode in size, leading to warnings such as: drivers/net/ethernet/freescale/dpaa/dpaa_eth.c:3280:12: warning: stack frame size (16664) exceeds limit (2048) in 'dpaa_eth_probe' [-Wframe-larger-than] The problem is twofold: - Reducing the array size to the boot-time num_possible_cpus() (rather than the compile-time NR_CPUS) creates a variable-length array, which should be avoided in the Linux kernel. - Using NR_CPUS as an array size makes the driver blow up in stack consumption with generic, as opposed to hand-crafted, .config files. A simple solution is to use dynamic allocation for num_possible_cpus() elements (aka a small number determined at runtime). Link: https://lore.kernel.org/all/202406261920.l5pzM1rj-lkp@intel.com/Signed-off-by:
Breno Leitao <leitao@debian.org> Acked-by:
-
- 14 Jul, 2024 5 commits
-
-
Jakub Kicinski authored
Merge tag 'ipsec-next-2024-07-13' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next Steffen Klassert says: ==================== pull request (net-next): ipsec-next 2024-07-13 1) Support sending NAT keepalives in ESP in UDP states. Userspace IKE daemon had to do this before, but the kernel can better keep track of it. From Eyal Birger. 2) Support IPsec crypto offload for IPv6 ESP and IPv4 UDP-encapsulated ESP data paths. Currently, IPsec crypto offload is enabled for GRO code path only. This patchset support UDP encapsulation for the non GRO path. From Mike Yu. * tag 'ipsec-next-2024-07-13' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next: xfrm: Support crypto offload for outbound IPv4 UDP-encapsulated ESP packet xfrm: Support crypto offload for inbound IPv4 UDP-encapsulated ESP packet xfrm: Allow UDP encapsulation in crypto offload control path xfrm: Support crypto offload for inbound IPv6 ESP packets not in GRO path xfrm: support sending NAT keepalives in ESP in UDP states ==================== Link: https://patch.msgid.link/20240713102416.3272997-1-steffen.klassert@secunet.comSigned-off-by:
-
Jakub Kicinski authored
Lorenzo Bianconi says: ==================== Introduce EN7581 ethernet support Add airoha_eth driver in order to introduce ethernet support for Airoha EN7581 SoC available on EN7581 development board. EN7581 mac controller is mainly composed by Frame Engine (FE) and QoS-DMA (QDMA) modules. FE is used for traffic offloading (just basic functionalities are supported now) while QDMA is used for DMA operation and QOS functionalities between mac layer and the dsa switch (hw QoS is not available yet and it will be added in the future). Currently only hw lan features are available, hw wan will be added with subsequent patches. ==================== Link: https://patch.msgid.link/cover.1720818878.git.lorenzo@kernel.orgSigned-off-by:
-
Lorenzo Bianconi authored
Add airoha_eth driver in order to introduce ethernet support for Airoha EN7581 SoC available on EN7581 development board (en7581-evb). EN7581 mac controller is mainly composed by the Frame Engine (PSE+PPE) and QoS-DMA (QDMA) modules. FE is used for traffic offloading (just basic functionalities are currently supported) while QDMA is used for DMA operations and QOS functionalities between the mac layer and the external modules conncted to the FE GDM ports (e.g MT7530 DSA switch or external phys). A general overview of airoha_eth architecture is reported below: ┌───────┐ ┌───────┐ │ QDMA2 │ │ QDMA1 │ └───┬───┘ └───┬───┘ │ │ ┌───────▼─────────────────────────────────────────────▼────────┐ │ │ │ P5 P0 │ │ │ │ │ │ │ ┌──────┐ │ P3 ├────► GDM3 │ │ │ └──────┘ │ │ │ │ ┌─────┐ │ │ │ PPE ◄────┤ P4 PSE │ └─────┘ │ │ │ │ │ │ │ │ ┌──────┐ │ P9 ├────► GDM4 │ │ │ └──────┘ │ │ │ │ │ │ │ P2 P1 │ └─────────┬───────────────────────────────────────────┬────────┘ │ │ ┌───▼──┐ ┌──▼───┐ │ GDM2 │ │ GDM1 │ └──────┘ └──┬───┘ │ ┌────▼─────┐ │ MT7530 │ └──────────┘ Currently only hw LAN features (QDMA1+GDM1) are available while hw WAN (QDMA2+GDM{2,3,4}) ones will be added with subsequent patches introducing traffic offloading support. Tested-by:Benjamin Larsson <benjamin.larsson@genexis.eu> Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/274945d2391c195098ab180a46d0617b18b9e42c.1720818878.git.lorenzo@kernel.orgSigned-off-by:
-
Lorenzo Bianconi authored
Introduce device-tree binding documentation for Airoha EN7581 ethernet mac controller. Reviewed-by:
Rob Herring (Arm) <robh@kernel.org> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== ice: Switch API optimizations Marcin Szycik says: Optimize the process of creating a recipe in the switch block by removing duplicate switch ID words and changing how result indexes are fitted into recipes. In many cases this can decrease the number of recipes required to add a certain set of rules, potentially allowing a more varied set of rules to be created. Total rule count will also increase, since less words will be left unused/wasted. There are only 64 rules available in total, so every one counts. After this modification, many fields and some structs became unused or were simplified, resulting in overall simpler implementation. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: ice: Add tracepoint for adding and removing switch rules ice: Remove unused members from switch API ice: Optimize switch recipe creation ice: remove unused recipe bookkeeping data ice: Simplify bitmap setting in adding recipe ice: Remove reading all recipes before adding a new one ice: Remove unused struct ice_prot_lkup_ext members ==================== Link: https://patch.msgid.link/20240711181312.2019606-1-anthony.l.nguyen@intel.comSigned-off-by:
-
- 13 Jul, 2024 33 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2024-07-11 (net/intel) This series contains updates to most Intel network drivers. Tony removes MODULE_AUTHOR from drivers containing the entry. Simon Horman corrects a kdoc entry for i40e. Pawel adds implementation for devlink param "local_forwarding" on ice. Michal removes unneeded call, and code, for eswitch rebuild for ice. Sasha removed a no longer used field from igc. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: igc: Remove the internal 'eee_advert' field ice: remove eswitch rebuild ice: Add support for devlink local_forwarding param i40e: correct i40e_addr_to_hkey() name in kdoc net: intel: Remove MODULE_AUTHORs ==================== Link: https://patch.msgid.link/20240711201932.2019925-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Easwar Hariharan authored
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/, fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists in the specification. Reviewed-by:
Martin Habets <habetsm.xilinx@gmail.com> Reviewed-by:
Simon Horman <horms@kernel.org> Signed-off-by:
Easwar Hariharan <eahariha@linux.microsoft.com> Link: https://patch.msgid.link/20240711052734.1273652-5-eahariha@linux.microsoft.comSigned-off-by:
-
Oleksij Rempel authored
This patch implements the TDR test procedure as described in "Application Note DP83TD510E Cable Diagnostics Toolkit revC", section 3.2. The procedure was tested with "draka 08 signalkabel 2x0.8mm". The reported cable length was 5 meters more for each 20 meters of actual cable length. For instance, a 20-meter cable showed as 25 meters, and a 40-meter cable showed as 50 meters. Since other parts of the diagnostics provided by this PHY (e.g., Active Link Cable Diagnostics) require accurate cable characterization to provide proper results, this tuning can be implemented in a separate patch/interface. Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> changes v2: - add comments - change post silence time to 1000ms Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20240712152848.2479912-1-o.rempel@pengutronix.deSigned-off-by:
-
Breno Leitao authored
Remove variables that are defined and incremented but never read. This issue appeared in network tests[1] as: drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c:38:6: warning: variable 'i' set but not used [-Wunused-but-set-variable] 38 | int i = 0; | ^ Link: https://netdev.bots.linux.dev/static/nipa/870263/13729811/build_clang/stderr [1] Signed-off-by:
-
Jakub Kicinski authored
ARFS depends on NTUPLE filters, but the inverse is not true. Drivers which don't support ARFS commonly still support NTUPLE filtering. mlx5 has a Kconfig option to disable ARFS (MLX5_EN_ARFS) and does not advertise NTUPLE filters as a feature at all when ARFS is compiled out. That's not correct, ntuple filters indeed still work just fine (as long as MLX5_EN_RXNFC is enabled). This is needed to make the RSS test not skip all RSS context related testing. Acked-by:
Saeed Mahameed <saeedm@nvidia.com> Link: https://patch.msgid.link/20240711223722.297676-1-kuba@kernel.orgSigned-off-by:
-
Matthieu Baerts (NGI0) authored
It looks like we missed these two errors recently: - SC2068: Double quote array expansions to avoid re-splitting elements. - SC2145: Argument mixes string and array. Use * or separate argument. Two simple fixes, it is not supposed to change the behaviour as the variable names should not have any spaces in their names. Still, better to fix them to easily spot new issues. Fixes: f265d311 ("selftests: mptcp: lib: use setup/cleanup_ns helpers") Signed-off-by:
Matthieu Baerts (NGI0) <matttbe@kernel.org> Reviewed-by:
-
Jakub Kicinski authored
Saeed Mahameed says: ==================== mlx5 misc 2023-07-08 (sf max eq) Link: https://patchwork.kernel.org/project/netdevbpf/patch/20240708080025.1593555-2-tariqt@nvidia.com/ ==================== Link: https://patch.msgid.link/20240712003310.355106-1-saeed@kernel.orgSigned-off-by:
-
Daniel Jurgens authored
If a maximum number of EQs has been set for an SF, use that amount. Signed-off-by:
Daniel Jurgens <danielj@nvidia.com> Reviewed-by:
William Tu <witu@nvidia.com> Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
-
Daniel Jurgens authored
If the user hasn't configured max_io_eqs set a low default. The SF driver shouldn't try to create more than this, but FW will enforce this limit. Signed-off-by:
-
Daniel Jurgens authored
When setting max_io_eqs for an SF function also set the sf_eq_usage_cap. This is to indicate to the SF driver from the PF that the user has set the max io eqs via devlink. So the SF driver can later query the proper max eq value from the new cap. Signed-off-by:
-
Daniel Jurgens authored
Expose a new cap sf_eq_usage. The vhca_resource_manager can write this cap, indicating the SF driver should use max_num_eqs_24b to determine how many EQs to use. Will be used in the next patch, to indicate to the SF driver from the PF that the user has set the max io eqs via devlink. So the SF driver can later query the proper max eq value from the new cap. devlink port function set pci/0000:08:00.0/32768 max_io_eqs 32 Signed-off-by:
-
Thorsten Blum authored
Change the data type of the variable freq in mvpp2_rx_time_coal_set() and mvpp2_tx_time_coal_set() to u32 because port->priv->tclk also has the data type u32. Change the data type of the function parameter clk_hz in mvpp2_usec_to_cycles() and mvpp2_cycles_to_usec() to u32 accordingly and remove the following Coccinelle/coccicheck warning reported by do_div.cocci: WARNING: do_div() does a 64-by-32 division, please consider using div64_ul instead Use min() to simplify the code and improve its readability. Compile-tested only. Signed-off-by:
Thorsten Blum <thorsten.blum@toblux.com> Reviewed-by:
-
Danielle Ratson authored
Currently, during the module firmware flashing process, unicast notifications are sent from the kernel using the same sequence number, making it impossible for user space to track missed notifications. Monotonically increase the message sequence number, so the order of notifications could be tracked effectively. Signed-off-by:
Danielle Ratson <danieller@nvidia.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
-
Jakub Kicinski authored
Kuniyuki Iwashima says: ==================== tcp: Make simultaneous connect() RFC-compliant. Patch 1 fixes an issue that BPF TCP option parser is triggered for ACK instead of SYN+ACK in the case of simultaneous connect(). Patch 2 removes an wrong assumption in tcp_ao/self-connnect tests. v2: https://lore.kernel.org/netdev/20240708180852.92919-1-kuniyu@amazon.com/ v1: https://lore.kernel.org/netdev/20240704035703.95065-1-kuniyu@amazon.com/ ==================== Link: https://patch.msgid.link/20240710171246.87533-1-kuniyu@amazon.comSigned-off-by:
-
Kuniyuki Iwashima authored
tcp_ao/self-connect.c checked the following SNMP stats before/after connect() to confirm that the test exercises the simultaneous connect() path. * TCPChallengeACK * TCPSYNChallenge But the stats should not be counted for self-connect in the first place, and the assumption is no longer true. Let's remove the check. Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
Dmitry Safonov <dima@arista.com> Link: https://patch.msgid.link/20240710171246.87533-3-kuniyu@amazon.comSigned-off-by:
-
Kuniyuki Iwashima authored
RFC 9293 states that in the case of simultaneous connect(), the connection gets established when SYN+ACK is received. [0] TCP Peer A TCP Peer B 1. CLOSED CLOSED 2. SYN-SENT --> <SEQ=100><CTL=SYN> ... 3. SYN-RECEIVED <-- <SEQ=300><CTL=SYN> <-- SYN-SENT 4. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED 5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ... 6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED 7. ... <SEQ=100><ACK=301><CTL=SYN,ACK> --> ESTABLISHED However, since commit 0c24604b ("tcp: implement RFC 5961 4.2"), such a SYN+ACK is dropped in tcp_validate_incoming() and responded with Challenge ACK. For example, the write() syscall in the following packetdrill script fails with -EAGAIN, and wrong SNMP stats get incremented. 0 socket(..., SOCK_STREAM|SOCK_NONBLOCK, IPPROTO_TCP) = 3 +0 connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress) +0 > S 0:0(0) <mss 1460,sackOK,TS val 1000 ecr 0,nop,wscale 8> +0 < S 0:0(0) win 1000 <mss 1000> +0 > S. 0:0(0) ack 1 <mss 1460,sackOK,TS val 3308134035 ecr 0,nop,wscale 8> +0 < S. 0:0(0) ack 1 win 1000 +0 write(3, ..., 100) = 100 +0 > P. 1:101(100) ack 1 -- # packetdrill cross-synack.pkt cross-synack.pkt:13: runtime error in write call: Expected result 100 but got -1 with errno 11 (Resource temporarily unavailable) # nstat ... TcpExtTCPChallengeACK 1 0.0 TcpExtTCPSYNChallenge 1 0.0 The problem is that bpf_skops_established() is triggered by the Challenge ACK instead of SYN+ACK. This causes the bpf prog to miss the chance to check if the peer supports a TCP option that is expected to be exchanged in SYN and SYN+ACK. Let's accept a bare SYN+ACK for active-open TCP_SYN_RECV sockets to avoid such a situation. Note that tcp_ack_snd_check() in tcp_rcv_state_process() is skipped not to send an unnecessary ACK, but this could be a bit risky for net.git, so this targets for net-next. Link: https://www.rfc-editor.org/rfc/rfc9293.html#section-3.5-7 [0] Signed-off-by: -
Peng Fan authored
Add install target for vsock to make Yocto easy to install the images. Signed-off-by:
Peng Fan <peng.fan@nxp.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Link: https://patch.msgid.link/20240710122728.45044-1-peng.fan@oss.nxp.comSigned-off-by:
-
Eric Dumazet authored
Following files are part of TCP stack: - net/ipv4/inet_connection_sock.c - net/ipv4/inet_hashtables.c - net/ipv4/inet_timewait_sock.c - net/ipv6/inet6_connection_sock.c - net/ipv6/inet6_hashtables.c Signed-off-by:
-
Steffen Klassert authored
Mike Yu says: ==================== Currently, IPsec crypto offload is enabled for GRO code path. However, there are other code paths where the XFRM stack is involved; for example, IPv6 ESP packets handled by xfrm6_esp_rcv() in ESP layer, and IPv4 UDP-encapsulated ESP packets handled by udp_rcv() in UDP layer. This patchset extends the crypto offload support to cover these two cases. This is useful for devices with traffic accounting (e.g., Android), where GRO can lead to inaccurate accounting on the underlying network. For example, VPN traffic might not be counted on the wifi network interface wlan0 if the packets are handled in GRO code path before entering the network stack for accounting. Below is the RX data path scenario the crypto offload can be applied to. +-----------+ +-------+ | HW Driver |-->| wlan0 |--------+ +-----------+ +-------+ | v +---------------+ +------+ +------>| Network Stack |-->| Apps | | +---------------+ +------+ | | | v +--------+ +------------+ | ipsec1 |<--| XFRM Stack | +--------+ +------------+ ==================== Signed-off-by:Steffen Klassert <steffen.klassert@secunet.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== idpf: XDP chapter I: convert Rx to libeth Alexander Lobakin says: XDP for idpf is currently 5 chapters: * convert Rx to libeth (this); * convert Tx and stats to libeth; * generic XDP and XSk code changes, libeth_xdp; * actual XDP for idpf via libeth_xdp; * XSk for idpf (^). Part I does the following: * splits &idpf_queue into 4 (RQ, SQ, FQ, CQ) and puts them on a diet; * ensures optimal cacheline placement, strictly asserts CL sizes; * moves currently unused/dead singleq mode out of line; * reuses libeth's Rx ptype definitions and helpers; * uses libeth's Rx buffer management for both header and payload; * eliminates memcpy()s and coherent DMA uses on hotpath, uses napi_build_skb() instead of in-place short skb allocation. Most idpf patches, except for the queue split, removes more lines than adds. Expect far better memory utilization and +5-8% on Rx depending on the case (+17% on skb XDP_DROP :>). * '200GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: idpf: use libeth Rx buffer management for payload buffer idpf: convert header split mode to libeth + napi_build_skb() libeth: support different types of buffers for Rx idpf: remove legacy Page Pool Ethtool stats idpf: reuse libeth's definitions of parsed ptype structures idpf: compile singleq code only under default-n CONFIG_IDPF_SINGLEQ idpf: merge singleq and splitq &net_device_ops idpf: strictly assert cachelines of queue and queue vector structures idpf: avoid bloating &idpf_q_vector with big %NR_CPUS idpf: split &idpf_queue into 4 strictly-typed queue structures idpf: stop using macros for accessing queue descriptors libeth: add cacheline / struct layout assertion helpers page_pool: use __cacheline_group_{begin, end}_aligned() cache: add __cacheline_group_{begin, end}_aligned() (+ couple more) ==================== Link: https://patch.msgid.link/20240710203031.188081-1-anthony.l.nguyen@intel.comSigned-off-by:
-
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextJakub Kicinski authored
Daniel Borkmann says: ==================== pull-request: bpf-next 2024-07-12 We've added 23 non-merge commits during the last 3 day(s) which contain a total of 18 files changed, 234 insertions(+), 243 deletions(-). The main changes are: 1) Improve BPF verifier by utilizing overflow.h helpers to check for overflows, from Shung-Hsi Yu. 2) Fix NULL pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXT when attr->attach_prog_fd was not specified, from Tengda Wu. 3) Fix arm64 BPF JIT when generating code for BPF trampolines with BPF_TRAMP_F_CALL_ORIG which corrupted upper address bits, from Puranjay Mohan. 4) Remove test_run callback from lwt_seg6local_prog_ops which never worked in the first place and caused syzbot reports, from Sebastian Andrzej Siewior. 5) Relax BPF verifier to accept non-zero offset on KF_TRUSTED_ARGS/ /KF_RCU-typed BPF kfuncs, from Matt Bobrowski. 6) Fix a long standing bug in libbpf with regards to handling of BPF skeleton's forward and backward compatibility, from Andrii Nakryiko. 7) Annotate btf_{seq,snprintf}_show functions with __printf, from Alan Maguire. 8) BPF selftest improvements to reuse common network helpers in sk_lookup test and dropping the open-coded inetaddr_len() and make_socket() ones, from Geliang Tang. * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (23 commits) selftests/bpf: Test for null-pointer-deref bugfix in resolve_prog_type() bpf: Fix null pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXT selftests/bpf: DENYLIST.aarch64: Skip fexit_sleep again bpf: use check_sub_overflow() to check for subtraction overflows bpf: use check_add_overflow() to check for addition overflows bpf: fix overflow check in adjust_jmp_off() bpf: Eliminate remaining "make W=1" warnings in kernel/bpf/btf.o bpf: annotate BTF show functions with __printf bpf, arm64: Fix trampoline for BPF_TRAMP_F_CALL_ORIG selftests/bpf: Close obj in error path in xdp_adjust_tail selftests/bpf: Null checks for links in bpf_tcp_ca selftests/bpf: Use connect_fd_to_fd in sk_lookup selftests/bpf: Use start_server_addr in sk_lookup selftests/bpf: Use start_server_str in sk_lookup selftests/bpf: Close fd in error path in drop_on_reuseport selftests/bpf: Add ASSERT_OK_FD macro selftests/bpf: Add backlog for network_helper_opts selftests/bpf: fix compilation failure when CONFIG_NF_FLOW_TABLE=m bpf: Remove tst_run from lwt_seg6local_prog_ops. bpf: relax zero fixed offset constraint on KF_TRUSTED_ARGS/KF_RCU ... ==================== Link: https://patch.msgid.link/20240712212448.5378-1-daniel@iogearbox.netSigned-off-by: -
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
Cross-merge networking fixes after downstream PR. Conflicts: drivers/net/ethernet/broadcom/bnxt/bnxt.c f7ce5eb2 ("bnxt_en: Fix crash in bnxt_get_max_rss_ctx_ring()") 20c8ad72 ("eth: bnxt: use the RSS context XArray instead of the local list") Adjacent changes: net/ethtool/ioctl.c 503757c8 ("net: ethtool: Fix RSS setting") eac9122f ("net: ethtool: record custom RSS contexts in the XArray") Signed-off-by:
-
Jakub Kicinski authored
Jakub Kicinski says: ==================== eth: bnxt: use the new RSS API Convert bnxt from using the set_rxfh API to separate create/modify/remove callbacks. Two small extensions to the core APIs are necessary: - the ability to discard contexts if for some catastrophic reasons device can no longer provide them; - the ability to reserve space in the context for RSS table growth. The driver is adjusted to store indirection tables on u32 to make it easier to use core structs directly. With that out of the way the conversion is fairly straightforward. Since the opposition to discarding contexts was relatively mild and its what bnxt does already, I'm sticking to that. We may very well need to revisit that at a later time. v1: https://lore.kernel.org/all/20240702234757.4188344-1-kuba@kernel.org/ ==================== Link: https://patch.msgid.link/20240711220713.283778-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Instead of allocating a separate indir table in the vnic use the one already present in the RSS context allocated by the core. This saves some LoC and also we won't have to worry about syncing the local version back to the core, once core learns how to dump contexts. Reviewed-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://patch.msgid.link/20240711220713.283778-12-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Ethtool core stores indirection table with u32 entries, "just to be safe". Switch the type in the driver, so that it's easier to swap local tables for the core ones. Memory allocations already use sizeof(*entry), switch the memset()s as well. Reviewed-by:
-
Jakub Kicinski authored
bnxt allocates tables of max size, and changes the used size based on number of active rings. The unused entries get padded out with zeros. bnxt_modify_rss() seems to always pad out the table of the main / default RSS context, instead of the table of the modified context. I haven't observed any behavior change due to this patch, so I don't think it's a fix. Not entirely sure what role the padding plays, 0 is a valid queue ID. Reviewed-by:
-
Jakub Kicinski authored
Core already maintains all RSS contexts in an XArray, no need to keep a second list in the driver. Remove bnxt_get_max_rss_ctx_ring() completely since core performs the same check already. Reviewed-by:
-
Jakub Kicinski authored
Core can allocate space for per-context driver-private data, use it for struct bnxt_rss_ctx. Inline bnxt_alloc_rss_ctx() at this point, most of the init (as in the actions bnxt_del_one_rss_ctx() will undo) is open coded in bnxt_create_rxfh_context(), anyway. Reviewed-by:
-
Jakub Kicinski authored
New RSS context API removes old contexts on netdev unregister. No need to wipe them manually. Reviewed-by:
-
Jakub Kicinski authored
Core will allocate IDs for the driver, from the range [1, BNXT_MAX_ETH_RSS_CTX], no need to track the allocations. Reviewed-by:
-
Jakub Kicinski authored
Use the new ethtool ops for RSS context management. The conversion is pretty straightforward cut / paste of the right chunks of the combined handler. Main change is that we let the core pick the IDs (bitmap will be removed separately for ease of review), so we need to tell the core when we lose a context. Since the new API passes rxfh as const, change bnxt_modify_rss() to also take const. Reviewed-by:
-
Jakub Kicinski authored
Contexts get deleted from FW when the device is down, but they are kept in SW and re-added back on open. bnxt_set_rxfh_context() apparently does not want to deal with complexity of dealing with both the device down and device up cases. This is perhaps acceptable for creating new contexts, but not being able to delete contexts makes core-driven cleanups messy. Specifically with the new RSS API core will try to delete contexts automatically after bringing the device down. Support the delete-while-down case. Skip the FW logic and delete just the driver state. Reviewed-by:
-
Jakub Kicinski authored
Some drivers (bnxt but I think also mlx5 from ML discussions) change the size of the indirection table depending on the number of Rx rings. Decouple the max table size from the size of the currently used table, so that we can reserve space in the context for table growth. Static members in ethtool_ops are good enough for now, we can add callbacks to read the max size more dynamically if someone needs that. Reviewed-by:
-
