- 08 May, 2024 4 commits
-
-
Eric Dumazet authored
Some usb drivers set small skb->truesize and break core networking stacks. In this patch, I removed one of the skb->truesize override. I also replaced one skb_clone() by an allocation of a fresh and small skb, to get minimally sized skbs, like we did in commit 1e2c6117 ("net: cdc_ncm: reduce skb truesize in rx path") and 4ce62d5b ("net: usb: ax88179_178a: stop lying about skb->truesize") Fixes: c9b37458 ("USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support") Signed-off-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20240506143939.3673865-1-edumazet@google.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Some usb drivers try to set small skb->truesize and break core networking stacks. In this patch, I removed one of the skb->truesize override. I also replaced one skb_clone() by an allocation of a fresh and small skb, to get minimally sized skbs, like we did in commit 1e2c6117 ("net: cdc_ncm: reduce skb truesize in rx path") and 4ce62d5b ("net: usb: ax88179_178a: stop lying about skb->truesize") Signed-off-by:
-
Eric Dumazet authored
Some usb drivers try to set small skb->truesize and break core networking stacks. I replace one skb_clone() by an allocation of a fresh and small skb, to get minimally sized skbs, like we did in commit 1e2c6117 ("net: cdc_ncm: reduce skb truesize in rx path") and 4ce62d5b ("net: usb: ax88179_178a: stop lying about skb->truesize") Fixes: 361459cd ("net: usb: aqc111: Implement RX data path") Signed-off-by:
-
John Hubbard authored
When building with clang, via: make LLVM=1 -C tools/testing/selftest ...clang warns about three variables that are not initialized in all cases: 1) The opt_ipproto_off variable is used uninitialized if "testname" is not "ip". Willem de Bruijn pointed out that this is an actual bug, and suggested the fix that I'm using here (thanks!). 2) The addr_len is used uninitialized, but only in the assert case, which bails out, so this is harmless. 3) The family variable in add_listener() is only used uninitialized in the error case (neither IPv4 nor IPv6 is specified), so it's also harmless. Fix by initializing each variable. Signed-off-by:John Hubbard <jhubbard@nvidia.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Acked-by:
Mat Martineau <martineau@kernel.org> Link: https://lore.kernel.org/r/20240506190204.28497-1-jhubbard@nvidia.comSigned-off-by:
-
- 07 May, 2024 33 commits
-
-
Florian Fainelli authored
Allow the Dynamic Interrupt Moderation (DIM) library to be built as a module. This is particularly useful in an Android GKI (Google Kernel Image) configuration where everything is built as a module, including Ethernet controller drivers. Having to build DIMLIB into the kernel image with potentially no user is wasteful. Signed-off-by:
Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by:
Alexander Lobakin <aleksander.lobakin@intel.com> Link: https://lore.kernel.org/r/20240506175040.410446-1-florian.fainelli@broadcom.comSigned-off-by:
-
Eric Dumazet authored
subflow_add_reset_reason(skb, ...) can fail. We can not assume mptcp_get_ext(skb) always return a non NULL pointer. syzbot reported: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 5098 Comm: syz-executor132 Not tainted 6.9.0-rc6-syzkaller-01478-gcdc74c9d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:subflow_v6_route_req+0x2c7/0x490 net/mptcp/subflow.c:388 Code: 8d 7b 07 48 89 f8 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 c0 01 00 00 0f b6 43 07 48 8d 1c c3 48 83 c3 18 48 89 d8 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 84 01 00 00 0f b6 5b 01 83 e3 0f 48 89 RSP: 0018:ffffc9000362eb68 EFLAGS: 00010206 RAX: 0000000000000003 RBX: 0000000000000018 RCX: ffff888022039e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88807d961140 R08: ffffffff8b6cb76b R09: 1ffff1100fb2c230 R10: dffffc0000000000 R11: ffffed100fb2c231 R12: dffffc0000000000 R13: ffff888022bfe273 R14: ffff88802cf9cc80 R15: ffff88802ad5a700 FS: 0000555587ad2380(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f420c3f9720 CR3: 0000000022bfc000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tcp_conn_request+0xf07/0x32c0 net/ipv4/tcp_input.c:7180 tcp_rcv_state_process+0x183c/0x4500 net/ipv4/tcp_input.c:6663 tcp_v6_do_rcv+0x8b2/0x1310 net/ipv6/tcp_ipv6.c:1673 tcp_v6_rcv+0x22b4/0x30b0 net/ipv6/tcp_ipv6.c:1910 ip6_protocol_deliver_rcu+0xc76/0x1570 net/ipv6/ip6_input.c:438 ip6_input_finish+0x186/0x2d0 net/ipv6/ip6_input.c:483 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5625 [inline] __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5739 netif_receive_skb_internal net/core/dev.c:5825 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5885 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1549 tun_get_user+0x2f35/0x4560 drivers/net/tun.c:2002 tun_chr_write_iter+0x113/0x1f0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2110 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xa84/0xcb0 fs/read_write.c:590 ksys_write+0x1a0/0x2c0 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 3e140491 ("mptcp: support rstreason for passive reset") Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Reviewed-by:
Matthieu Baerts (NGI0) <matttbe@kernel.org> Reviewed-by:
Jason Xing <kerneljasonxing@gmail.com> Link: https://lore.kernel.org/r/20240506123032.3351895-1-edumazet@google.comSigned-off-by:
-
Florian Westphal authored
Netdev CI reports occasional failures with this test ("ERROR: ns2-dX6bUE did not pick up tcp connection from peer"). Add explicit busywait call until the initial connection attempt shows up in conntrack rather than a one-shot 'must exist' check. Signed-off-by:Florian Westphal <fw@strlen.de> Link: https://lore.kernel.org/r/20240506114320.12178-1-fw@strlen.deSigned-off-by:
-
Eric Dumazet authored
Simon reported that ndo_change_mtu() methods were never updated to use WRITE_ONCE(dev->mtu, new_mtu) as hinted in commit 501a90c9 ("inet: protect against too small mtu values.") We read dev->mtu without holding RTNL in many places, with READ_ONCE() annotations. It is time to take care of ndo_change_mtu() methods to use corresponding WRITE_ONCE() Signed-off-by:
Simon Horman <horms@kernel.org> Closes: https://lore.kernel.org/netdev/20240505144608.GB67882@kernel.org/Reviewed-by:
Jacob Keller <jacob.e.keller@intel.com> Reviewed-by:
Sabrina Dubroca <sd@queasysnail.net> Reviewed-by:
Shannon Nelson <shannon.nelson@amd.com> Link: https://lore.kernel.org/r/20240506102812.3025432-1-edumazet@google.comSigned-off-by:
-
Jeff Johnson authored
make C=1 reports: warning: Function parameter or struct member 'mrtt' not described in 'ccid2_rtt_estimator' So document the 'mrtt' parameter. Signed-off-by:
Jeff Johnson <quic_jjohnson@quicinc.com> Reviewed-by:
-
Matthias Schiffer authored
The embedded PHYs of the 88E6250 family switches are very basic - they do not even have an Extended Address / Page register. This adds support for the PHYs to the driver to set up PHY interrupts and retrieve error stats. To deal with PHYs without a page register, "simple" variants of all stat handling functions are introduced. The code should work with all 88E6250 family switches (6250/6220/6071/ 6070/6020). The PHY ID 0x01410db0 was read from a 88E6020, under the assumption that all switches of this family use the same ID. The spec only lists the prefix 0x01410c00 and leaves the last 10 bits as reserved, but that seems too unspecific to be useful, as it would cover several existing PHY IDs already supported by the driver; therefore, the ID read from the actual hardware is used. Signed-off-by:
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/0695f699cd942e6e06da9d30daeedfd47785bc01.1714643285.git.matthias.schiffer@ew.tq-group.comSigned-off-by:
-
Matthias Schiffer authored
The list of stat registers is read-only, so we can declare it as const. Signed-off-by:
-
Paolo Abeni authored
Daniel Jurgens says: ==================== Remove RTNL lock protection of CVQ Currently the buffer used for control VQ commands is protected by the RTNL lock. Previously this wasn't a major concern because the control VQ was only used during device setup and user interaction. With the recent addition of dynamic interrupt moderation the control VQ may be used frequently during normal operation. This series removes the RNTL lock dependency by introducing a mutex to protect the control buffer and writing SGs to the control VQ. v6: - Rebased over new stats code. - Added comment to cvq_lock, init the mutex unconditionally, and replaced some duplicate code with a goto. - Fixed minor grammer errors, checkpatch warnings, and clarified a comment. v5: - Changed cvq_lock to a mutex. - Changed dim_lock to mutex, because it's held taking the cvq_lock. - Use spin/mutex_lock/unlock vs guard macros. v4: - Protect dim_enabled with same lock as well intr_coal. - Rename intr_coal_lock to dim_lock. - Remove some scoped_guard where the error path doesn't have to be in the lock. v3: - Changed type of _offloads to __virtio16 to fix static analysis warning. - Moved a misplaced hunk to the correct patch. v2: - New patch to only process the provided queue in virtnet_dim_work - New patch to lock per queue rx coalescing structure. ==================== Link: https://lore.kernel.org/r/20240503202445.1415560-1-danielj@nvidia.comSigned-off-by:
-
Daniel Jurgens authored
The rtnl lock is no longer needed to protect the control buffer and command VQ. Signed-off-by:
Daniel Jurgens <danielj@nvidia.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
Heng Qi <hengqi@linux.alibaba.com> Tested-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
-
Daniel Jurgens authored
Once the RTNL locking around the control buffer is removed there can be contention on the per queue RX interrupt coalescing data. Use a mutex per queue. A mutex is required because virtnet_send_command can sleep. Signed-off-by:
-
Daniel Jurgens authored
Since we no longer have to hold the RTNL lock here just do updates for the specified queue. Signed-off-by:
-
Daniel Jurgens authored
The command VQ will no longer be protected by the RTNL lock. Use a mutex to protect the control buffer header and the VQ. Signed-off-by:
-
Daniel Jurgens authored
Allocate memory for the data when it's used. Ideally the struct could be on the stack, but we can't DMA stack memory. With this change only the header and status memory are shared between commands, which will allow using a tighter lock than RTNL. Signed-off-by:
-
Daniel Jurgens authored
Stop storing RSS setting in the control buffer. This is prep work for removing RTNL lock protection of the control buffer. Signed-off-by:
-
Arınç ÜNAL authored
Currently, the MT7530 DSA subdriver configures the MT7530 switch to provide direct access to switch PHYs, meaning, the switch PHYs listen on the MDIO bus the switch listens on. The PHY muxing feature makes use of this. This is problematic as the PHY may be attached before the switch is initialised, in which case, the PHY will fail to be attached. Since commit 91374ba5 ("net: dsa: mt7530: support OF-based registration of switch MDIO bus"), we can describe the switch PHYs on the MDIO bus of the switch on the device tree. Extend the check to detect PHY muxing when the PHY is defined on the MDIO bus of the switch on the device tree. When the PHY is described this way, the switch will be initialised first, then the switch MDIO bus will be registered. Only after these steps, the PHY will be attached. Signed-off-by:
Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by:
Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/20240430-b4-for-netnext-mt7530-use-switch-mdio-bus-for-phy-muxing-v2-1-9104d886d0db@arinc9.comSigned-off-by:
-
Paolo Abeni authored
Eric Dumazet says: ==================== rtnetlink: more rcu conversions for rtnl_fill_ifinfo() We want to no longer rely on RTNL for "ip link show" command. This is a long road, this series takes care of some parts. ==================== Link: https://lore.kernel.org/r/20240503192059.3884225-1-edumazet@google.comSigned-off-by:
-
Eric Dumazet authored
We want to be able to run rtnl_fill_ifinfo() under RCU protection instead of RTNL in the future. All rtnl_link_ops->get_link_net() methods already using dev_net() are ready. I added READ_ONCE() annotations on others. Signed-off-by:
-
Eric Dumazet authored
dev->xdp_prog is protected by RCU, we can lift RTNL requirement from rtnl_xdp_prog_skb(). Signed-off-by:
-
Eric Dumazet authored
Change dev_change_proto_down() and dev_change_proto_down_reason() to write once on dev->proto_down and dev->proto_down_reason. Then rtnl_fill_proto_down() can use READ_ONCE() annotations and run locklessly. rtnl_proto_down_size() should assume worst case, because readng dev->proto_down_reason multiple times would be racy without RTNL in the future. Signed-off-by:
-
Eric Dumazet authored
Following device fields can be read locklessly in rtnl_fill_ifinfo() : type, ifindex, operstate, link_mode, mtu, min_mtu, max_mtu, group, promiscuity, allmulti, num_tx_queues, gso_max_segs, gso_max_size, gro_max_size, gso_ipv4_max_size, gro_ipv4_max_size, tso_max_size, tso_max_segs, num_rx_queues. Signed-off-by:
-
Eric Dumazet authored
In the following patch we want to read dev->allmulti and dev->promiscuity locklessly from rtnl_fill_ifinfo() In this patch I change __dev_set_promiscuity() and __dev_set_allmulti() to write these fields (and dev->flags) only if they succeed, with WRITE_ONCE() annotations. Signed-off-by:
-
Eric Dumazet authored
rtnl_fill_ifinfo() can read dev->tx_queue_len locklessly, granted we add corresponding READ_ONCE()/WRITE_ONCE() annotations. Add missing READ_ONCE(dev->tx_queue_len) in teql_enqueue() Signed-off-by:
-
Eric Dumazet authored
We can use netdev_copy_name() to no longer rely on RTNL to fetch dev->name. Signed-off-by:
-
Eric Dumazet authored
dev->qdisc can be read using RCU protection. Signed-off-by:
-
Paolo Abeni authored
says: ==================== net: qede: don't restrict error codes This series fixes the qede driver, so that when a helper function fails, then the callee should return the returned error code, instead just assuming that the error is eg. -EINVAL. The patches in this series, reduces the change of future bugs, so new error codes can be returned from the helpers, without having to update the call sites. This is a follow-up to my recent series "net: qede: avoid overruling error codes", which fixed the cases where the implicit assumption of failing with specific error codes had been broken. https://lore.kernel.org/netdev/20240426091227.78060-1-ast@fiberby.net/ Asbjørn Sloth Tønnesen (3): net: qede: use return from qede_parse_actions() for flow_spec net: qede: use return from qede_flow_spec_validate_unused() net: qede: use return from qede_flow_parse_ports() .../net/ethernet/qlogic/qede/qede_filter.c | 27 ++++++++++++------- 1 file changed, 18 insertions(+), 9 deletions(-) ==================== Link: https://lore.kernel.org/r/20240503105505.839342-1-ast@fiberby.netSigned-off-by:
-
Asbjørn Sloth Tønnesen authored
When calling qede_flow_parse_ports(), then the return code was only used for a non-zero check, and then -EINVAL was returned. qede_flow_parse_ports() can currently fail with: * -EINVAL This patch changes qede_flow_parse_v{4,6}_common() to use the actual return code from qede_flow_parse_ports(), so it's no longer assumed that all errors are -EINVAL. Only compile tested. Signed-off-by:Asbjørn Sloth Tønnesen <ast@fiberby.net> Reviewed-by:
-
Asbjørn Sloth Tønnesen authored
When calling qede_flow_spec_validate_unused() then the return code was only used for a non-zero check, and then -EOPNOTSUPP was returned. qede_flow_spec_validate_unused() can currently fail with: * -EOPNOTSUPP This patch changes qede_flow_spec_to_rule() to use the actual return code from qede_flow_spec_validate_unused(), so it's no longer assumed that all errors are -EOPNOTSUPP. Only compile tested. Signed-off-by:
-
Asbjørn Sloth Tønnesen authored
In qede_flow_spec_to_rule(), when calling qede_parse_actions() then the return code was only used for a non-zero check, and then -EINVAL was returned. qede_parse_actions() can currently fail with: * -EINVAL * -EOPNOTSUPP Commit 319a1d19 ("flow_offload: check for basic action hw stats type") broke the implicit assumption that it could only fail with -EINVAL, by changing it to return -EOPNOTSUPP, when hardware stats are requested. However AFAICT it's not possible to trigger qede_parse_actions() to return -EOPNOTSUPP, when called from qede_flow_spec_to_rule(), as hardware stats can't be requested by ethtool_rx_flow_rule_create(). This patch changes qede_flow_spec_to_rule() to use the actual return code from qede_parse_actions(), so it's no longer assumed that all errors are -EINVAL. Only compile tested. Signed-off-by:
-
Jakub Kicinski authored
Merge tag 'ipsec-next-2024-05-03' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next Steffen Klassert says: ==================== pull request (net-next): ipsec-next 2024-05-03 1) Remove Obsolete UDP_ENCAP_ESPINUDP_NON_IKE Support. This was defined by an early version of an IETF draft that did not make it to a standard. 2) Introduce direction attribute for xfrm states. xfrm states have a direction, a stsate can be used either for input or output packet processing. Add a direction to xfrm states to make it clear for what a xfrm state is used. * tag 'ipsec-next-2024-05-03' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next: xfrm: Restrict SA direction attribute to specific netlink message types xfrm: Add dir validation to "in" data path lookup xfrm: Add dir validation to "out" data path lookup xfrm: Add Direction to the SA in or out udpencap: Remove Obsolete UDP_ENCAP_ESPINUDP_NON_IKE Support ==================== Link: https://lore.kernel.org/r/20240503082732.2835810-1-steffen.klassert@secunet.comSigned-off-by:
-
Shi-Sheng Yang authored
This patch fixes the spelling mistakes in comments. The changes were generated using codespell and reviewed manually. eariler -> earlier greceful -> graceful Signed-off-by:
Shi-Sheng Yang <fourcolor4c@gmail.com> Reviewed-by:
-
Simon Horman authored
According to GCC, the constriction of irq_name in otx2_open() may, theoretically, be truncated. This patch takes the approach of treating such a situation as an error which it detects by making use of the return value of snprintf, which is the total number of bytes, excluding the trailing '\0', that would have been written. Based on the approach taken to a similar problem in commit 54b90943 ("rtc: fix snprintf() checking in is_rtc_hctosys()") Flagged by gcc-13 W=1 builds as: .../otx2_pf.c:1933:58: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=] 1933 | snprintf(irq_name, NAME_SIZE, "%s-rxtx-%d", pf->netdev->name, | ^ .../otx2_pf.c:1933:17: note: 'snprintf' output between 8 and 33 bytes into a destination of size 32 1933 | snprintf(irq_name, NAME_SIZE, "%s-rxtx-%d", pf->netdev->name, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1934 | qidx); | ~~~~~ Compile tested only. Tested-by:
Geetha sowjanya <gakula@marvell.com> Reviewed-by:
-
Dr. David Alan Gilbert authored
This list looks like it's been unused since the OF conversion in 2008 in commit 826b6cfc ("fore200e: Convert over to pure OF driver.") This also means we can remove the 'entry' member for the list. Build tested only. Signed-off-by:
Dr. David Alan Gilbert <linux@treblig.org> Reviewed-by:
Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/r/20240503001822.183061-1-linux@treblig.orgSigned-off-by:
-
Shailend Chand authored
The new netdev queue api is implemented for gve. Tested-by:
Mina Almasry <almasrymina@google.com> Reviewed-by:
Praveen Kaligineedi <pkaligineedi@google.com> Reviewed-by:
Harshitha Ramamurthy <hramamurthy@google.com> Signed-off-by:
Shailend Chand <shailend@google.com> Link: https://lore.kernel.org/all/20240501232549.1327174-11-shailend@google.com/Signed-off-by:
-
- 06 May, 2024 3 commits
-
-
Paolo Abeni authored
Felix Fietkau says: ==================== Add TCP fraglist GRO support When forwarding TCP after GRO, software segmentation is very expensive, especially when the checksum needs to be recalculated. One case where that's currently unavoidable is when routing packets over PPPoE. Performance improves significantly when using fraglist GRO implemented in the same way as for UDP. When NETIF_F_GRO_FRAGLIST is enabled, perform a lookup for an established socket in the same netns as the receiving device. While this may not cover all relevant use cases in multi-netns configurations, it should be good enough for most configurations that need this. Here's a measurement of running 2 TCP streams through a MediaTek MT7622 device (2-core Cortex-A53), which runs NAT with flow offload enabled from one ethernet port to PPPoE on another ethernet port + cake qdisc set to 1Gbps. rx-gro-list off: 630 Mbit/s, CPU 35% idle rx-gro-list on: 770 Mbit/s, CPU 40% idle Changes since v4: - add likely() to prefer the non-fraglist path in check Changes since v3: - optimize __tcpv4_gso_segment_csum - add unlikely() - reorder dev_net/skb_gro_network_header calls after NETIF_F_GRO_FRAGLIST check - add support for ipv6 nat - drop redundant pskb_may_pull check Changes since v2: - create tcp_gro_header_pull helper function to pull tcp header only once - optimize __tcpv4_gso_segment_list_csum, drop obsolete flags check Changes since v1: - revert bogus tcp flags overwrite on segmentation - fix kbuild issue with !CONFIG_IPV6 - only perform socket lookup for the first skb in the GRO train Changes since RFC: - split up patches - handle TCP flags mutations ==================== Link: https://lore.kernel.org/r/20240502084450.44009-1-nbd@nbd.nameSigned-off-by:
-
Felix Fietkau authored
When forwarding TCP after GRO, software segmentation is very expensive, especially when the checksum needs to be recalculated. One case where that's currently unavoidable is when routing packets over PPPoE. Performance improves significantly when using fraglist GRO implemented in the same way as for UDP. When NETIF_F_GRO_FRAGLIST is enabled, perform a lookup for an established socket in the same netns as the receiving device. While this may not cover all relevant use cases in multi-netns configurations, it should be good enough for most configurations that need this. Here's a measurement of running 2 TCP streams through a MediaTek MT7622 device (2-core Cortex-A53), which runs NAT with flow offload enabled from one ethernet port to PPPoE on another ethernet port + cake qdisc set to 1Gbps. rx-gro-list off: 630 Mbit/s, CPU 35% idle rx-gro-list on: 770 Mbit/s, CPU 40% idle Acked-by:
Felix Fietkau <nbd@nbd.name> Reviewed-by:
David Ahern <dsahern@kernel.org> Reviewed-by:
-
Felix Fietkau authored
Pull the code out of tcp_gro_receive in order to access the tcp header from tcp4/6_gro_receive. Acked-by:
-
