- 06 Mar, 2024 12 commits
-
-
Jakub Kicinski authored
Oleksij Rempel says: ==================== net: ethernet: Rework EEE with Andrew's permission I'll continue mainlining this patches: ============================================================== Most MAC drivers get EEE wrong. The API to the PHY is not very obvious, which is probably why. Rework the API, pushing most of the EEE handling into phylib core, leaving the MAC drivers to just enable/disable support for EEE in there change_link call back. MAC drivers are now expect to indicate to phylib if they support EEE. This will allow future patches to configure the PHY to advertise no EEE link modes when EEE is not supported. The information could also be used to enable SmartEEE if the PHY supports it. With these changes, the uAPI configuration eee_enable becomes a global on/off. tx-lpi must also be enabled before EEE is enabled. This fits the discussion here: https://lore.kernel.org/netdev/af880ce8-a7b8-138e-1ab9-8c89e662eecf@gmail.com/T/ This patchset puts in place all the infrastructure, and converts one MAC driver to the new API. Following patchsets will convert other MAC drivers, extend support into phylink, and when all MAC drivers are converted to the new scheme, clean up some unneeded code. ==================== Link: https://lore.kernel.org/r/20240302195306.3207716-1-o.rempel@pengutronix.deSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Andrew Lunn authored
The enabling/disabling of EEE in the MAC should happen as a result of auto negotiation. So move the enable/disable into fec_enet_adjust_link() which gets called by phylib when there is a change in link status. fec_enet_set_eee() now just stores away the LPI timer value. Everything else is passed to phylib, so it can correctly setup the PHY. fec_enet_get_eee() relies on phylib doing most of the work, the MAC driver just adds the LPI timer value. Call phy_support_eee() if the quirk is present to indicate the MAC actually supports EEE. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> (On iMX8MP debix) Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by:
Wei Fang <wei.fang@nxp.com> Link: https://lore.kernel.org/r/20240302195306.3207716-8-o.rempel@pengutronix.deSigned-off-by:
-
Andrew Lunn authored
FEC is about to get its EEE code re-written. To allow this, move fec_enet_eee_mode_set() before fec_enet_adjust_link() which will need to call it. Signed-off-by:
-
Andrew Lunn authored
In order for EEE to operate, both the MAC and the PHY need to support it, similar to how pause works. With some exception - a number of PHYs have SmartEEE or AutoGrEEEn support in order to provide some EEE-like power savings with non-EEE capable MACs. Copy the pause concept and add the call phy_support_eee() which the MAC makes after connecting the PHY to indicate it supports EEE. phylib will then advertise EEE when auto-neg is performed. Signed-off-by:
-
Andrew Lunn authored
The MAC driver changes its EEE hardware configuration in its adjust_link callback. This is called when auto-neg completes. Disabling EEE via eee_enabled false will trigger an autoneg, and as a result the adjust_link callback will be called with phydev->enable_tx_lpi set to false. Similarly, eee_enabled set to true and with a change of advertised link modes will result in a new autoneg, and a call the adjust_link call. If set_eee is called with only a change to tx_lpi_enabled which does not trigger an auto-neg, it is necessary to call the adjust_link callback so that the MAC is reconfigured to take this change into account. When setting phydev->enable_tx_lpi, take both eee_enabled and tx_lpi_enabled into account, so the MAC drivers just needs to act on phydev->enable_tx_lpi and not the whole EEE configuration. The same check should be done for tx_lpi_timer too. Signed-off-by:
Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by:
-
Andrew Lunn authored
Have phylib keep track of the EEE configuration. This simplifies the MAC drivers, in that they don't need to store it. Future patches to phylib will also make use of this information to further simplify the MAC drivers. Reviewed-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Andrew Lunn authored
MAC drivers which support EEE need to know the results of the EEE auto-neg in order to program the hardware to perform EEE or not. The oddly named phy_init_eee() can be used to determine this, it returns 0 if EEE should be used, or a negative error code, e.g. -EOPPROTONOTSUPPORT if the PHY does not support EEE or negotiate resulted in it not being used. However, many MAC drivers get this wrong. Add phydev->enable_tx_lpi which indicates the result of the autoneg for EEE, including if EEE is administratively disabled with ethtool. The MAC driver can then access this in the same way as link speed and duplex in the adjust link callback. If enable_tx_lpi is true, the MAC should send low power indications and does not need to consider anything else with respect to EEE. Reviewed-by:
-
Russell King authored
Add helpers that phylib and phylink can use to manage EEE configuration and determine whether the MAC should be permitted to use LPI based on that configuration. Signed-off-by:
-
Heiner Kallweit authored
This function is used with the set_eee() ethtool operation. Certain fields of struct ethtool_keee() are relevant only for the get_eee() operation. In addition, in case of the ioctl interface, we have no guarantee that userspace sends sane values in struct ethtool_eee. Therefore explicitly ignore all fields not needed for set_eee(). This protects from drivers trying to use unchecked and unreliable data, relying on specific userspace behavior. Note: Such unsafe driver behavior has been found and fixed in the tg3 driver. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
-
Kees Cook authored
While testing for places where zero-sized destinations were still showing up in the kernel, sock_copy() and inet_reqsk_clone() were found, which are using very specific memcpy() offsets for both avoiding a portion of struct sock, and copying beyond the end of it (since struct sock is really just a common header before the protocol-specific allocation). Instead of trying to unravel this historical lack of container_of(), just switch to unsafe_memcpy(), since that's effectively what was happening already (memcpy() wasn't checking 0-sized destinations while the code base was being converted away from fake flexible arrays). Avoid the following false positive warning with future changes to CONFIG_FORTIFY_SOURCE: memcpy: detected field-spanning write (size 3068) of destination "&nsk->__sk_common.skc_dontcopy_end" at net/core/sock.c:2057 (size 0) Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240304212928.make.772-kees@kernel.orgSigned-off-by:
-
Breno Leitao authored
Commit 3e2f544d ("net: get stats64 if device if driver is configured") moved the callback to dev_get_tstats64() to net core, so, unless the driver is doing some custom stats collection, it does not need to set .ndo_get_stats64. Since this driver is now relying in NETDEV_PCPU_STAT_TSTATS, then, it doesn't need to set the dev_get_tstats64() generic .ndo_get_stats64 function pointer. Signed-off-by:
Breno Leitao <leitao@debian.org> Reviewed-by:
Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20240304183810.1474883-2-leitao@debian.orgSigned-off-by:
-
Breno Leitao authored
With commit 34d21de9 ("net: Move {l,t,d}stats allocation to core and convert veth & vrf"), stats allocation could be done on net core instead of in this driver. With this new approach, the driver doesn't have to bother with error handling (allocation failure checking, making sure free happens in the right spot, etc). This is core responsibility now. Remove the allocation in the tun/tap driver and leverage the network core allocation instead. Signed-off-by:
-
- 05 Mar, 2024 28 commits
-
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
-
Jakub Kicinski authored
Ricardo B. Marliere says: ==================== net: constify struct class usage This is a simple and straight forward cleanup series that aims to make the class structures in net constant. This has been possible since 2023 [1]. [1]: https://lore.kernel.org/all/2023040248-customary-release-4aec@gregkh/ ==================== Link: https://lore.kernel.org/r/20240302-class_cleanup-net-next-v1-0-8fa378595b93@marliere.netSigned-off-by:
-
Ricardo B. Marliere authored
Since commit 43a7206b ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the nfc_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Suggested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ricardo B. Marliere <ricardo@marliere.net> Reviewed-by:
-
Ricardo B. Marliere authored
Since commit 43a7206b ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the wwan_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Suggested-by:
Sergey Ryazanov <ryazanov.s.a@gmail.com> Link: https://lore.kernel.org/r/20240302-class_cleanup-net-next-v1-5-8fa378595b93@marliere.netSigned-off-by:
-
Ricardo B. Marliere authored
Since commit 43a7206b ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the wwan_hwsim_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Suggested-by:
-
Ricardo B. Marliere authored
Since commit 43a7206b ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the ppp_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Suggested-by:
-
Ricardo B. Marliere authored
Since commit 43a7206b ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the framer_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Suggested-by:
Herve Codina <herve.codina@bootlin.com> Link: https://lore.kernel.org/r/20240302-class_cleanup-net-next-v1-2-8fa378595b93@marliere.netSigned-off-by:
-
Ricardo B. Marliere authored
Since commit 43a7206b ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the hnae_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Suggested-by:
-
Jakub Kicinski authored
Horatiu Vultur says: ==================== net: phy: micrel: lan8814 erratas Add two erratas for lan8814. First one fix the led which might stay on even that there is no link. The second one improves increases length of the cable that can be used when used in 1000Base-T. ==================== Link: https://lore.kernel.org/r/20240304091548.1386022-1-horatiu.vultur@microchip.comSigned-off-by:
-
Horatiu Vultur authored
When the length of the cable is more than 100m and the lan8814 is configured to run in 1000Base-T Slave then the register of the device needs to be optimized. Workaround this by setting the measure time to a value of 0xb. This value can be set regardless of the configuration. This issue is described in 'LAN8814 Silicon Errata and Data Sheet Clarification' and according to that, this will not be corrected in a future silicon revision. Reviewed-by:
Wojciech Drewek <wojciech.drewek@intel.com> Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by:
Arun Ramadoss <arun.ramadoss@microchip.com> Link: https://lore.kernel.org/r/20240304091548.1386022-3-horatiu.vultur@microchip.comSigned-off-by:
-
Horatiu Vultur authored
Lan8814 phy led behavior is not correct. It was noticed that the led still remains ON when the cable is unplugged while there was traffic passing at that time. The fix consists in clearing bit 10 of register 0x38, in this way the led behaviour is correct and gets OFF when there is no link. Reviewed-by:
-
Jakub Kicinski authored
Ido Schimmel says: ==================== selftests: forwarding: Various improvements This patchset speeds up the multipath tests (patches #1-#2) and makes other tests more stable (patches #3-#6) so that they will not randomly fail in the netdev CI. On my system, after applying the first two patches, the run time of gre_multipath_nh_res.sh is reduced by over 90%. ==================== Link: https://lore.kernel.org/r/20240304095612.462900-1-idosch@nvidia.comSigned-off-by:
-
Ido Schimmel authored
These tests generate various IPv6 flows, encapsulate them in GRE packets and check that the encapsulated packets are distributed between the available nexthops according to the configured weights. Unlike the corresponding IPv4 tests, these tests sometimes fail in the netdev CI because of large discrepancies between the expected and measured ratios [1]. This can be explained by the fact that the IPv4 tests generate about 3,600 different flows whereas the IPv6 tests only generate about 784 different flows (potentially by mistake). Fix by aligning the IPv6 tests to the IPv4 ones and increase the number of generated flows. [1] [...] # TEST: ping [ OK ] # INFO: Running IPv6 over GRE over IPv4 multipath tests # TEST: ECMP [FAIL] # Too large discrepancy between expected and measured ratios # INFO: Expected ratio 1.00 Measured ratio 1.18 [...] Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/20240304095612.462900-7-idosch@nvidia.comSigned-off-by:
-
Ido Schimmel authored
These tests sometimes fail on the netdev CI because the expected number of packets is larger than expected [1]. Make the tests more robust by specifically matching on VXLAN encapsulated packets and allowing up to five stray packets instead of just two. [1] [...] # TEST: VXLAN: ECN encap: 0x00->0x00 [FAIL] # v1: Expected to capture 10 packets, got 13. # TEST: VXLAN: ECN encap: 0x01->0x01 [ OK ] # TEST: VXLAN: ECN encap: 0x02->0x02 [ OK ] # TEST: VXLAN: ECN encap: 0x03->0x02 [ OK ] [...] Signed-off-by:
-
Ido Schimmel authored
The ageing time used by the test is too short for debug kernels and results in entries being aged out prematurely [1]. Fix by increasing the ageing time. [1] # ./vxlan_bridge_1q.sh [...] INFO: learning vlan 10 TEST: VXLAN: flood before learning [ OK ] TEST: VXLAN: show learned FDB entry [ OK ] TEST: VXLAN: learned FDB entry [FAIL] swp4: Expected to capture 0 packets, got 10. RTNETLINK answers: No such file or directory TEST: VXLAN: deletion of learned FDB entry [ OK ] TEST: VXLAN: Ageing of learned FDB entry [FAIL] swp4: Expected to capture 0 packets, got 10. TEST: VXLAN: learning toggling on bridge port [ OK ] [...] Signed-off-by: -
Ido Schimmel authored
The test configures a policer with a rate of 80Mbps and expects to measure a rate close to it. This is a too high rate for debug kernels, causing the test to fail [1]. Fix by reducing the rate to 10Mbps. [1] # ./tc_police.sh TEST: police on rx [FAIL] Expected rate 76.2Mbps, got 29.6Mbps, which is -61% off. Required accuracy is +-10%. TEST: police on tx [FAIL] Expected rate 76.2Mbps, got 30.4Mbps, which is -60% off. Required accuracy is +-10%. Signed-off-by: -
Ido Schimmel authored
The various multipath tests use mausezahn to generate different flows and check how they are distributed between the available nexthops. The tool is currently invoked with an hard coded transmission delay of 1 ms. This is unnecessary when the tests are run with veth pairs and needlessly prolongs the tests. Parametrize this delay and default it to 0 us. It can be overridden using the forwarding.config file. On my system, this reduces the run time of router_multipath.sh by 93%. Signed-off-by:
-
Ido Schimmel authored
The multipath tests currently test both the L3 and L4 multipath hash policies for IPv6, but only the L4 policy for IPv4. The reason is mostly historic: When the initial multipath test was added (router_multipath.sh) the IPv6 L4 policy did not exist and was later added to the test. The other multipath tests copied this pattern although there is little value in testing both policies. Align the IPv4 and IPv6 tests and only test the L4 policy. On my system, this reduces the run time of router_multipath.sh by 89% because of the repeated ping6 invocations to randomize the flow label. Signed-off-by:
-
Eric Dumazet authored
Many syzbot reports show extreme rtnl pressure, and many of them hint that smc acquires rtnl in netns creation for no good reason [1] This patch returns early from smc_pnet_net_init() if there is no netdevice yet. I am not even sure why smc_pnet_create_pnetids_list() even exists, because smc_pnet_netdev_event() is also calling smc_pnet_add_base_pnetid() when handling NETDEV_UP event. [1] extract of typical syzbot reports 2 locks held by syz-executor.3/12252: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.4/12253: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.1/12257: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.2/12261: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.0/12265: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.3/12268: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.4/12271: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.1/12274: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.2/12280: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 Signed-off-by:Eric Dumazet <edumazet@google.com> Cc: Wenjia Zhang <wenjia@linux.ibm.com> Cc: Jan Karcher <jaka@linux.ibm.com> Cc: "D. Wythe" <alibuda@linux.alibaba.com> Cc: Tony Lu <tonylu@linux.alibaba.com> Cc: Wen Gu <guwen@linux.alibaba.com> Reviewed-by:
Wenjia Zhang <wenjia@linux.ibm.com> Link: https://lore.kernel.org/r/20240302100744.3868021-1-edumazet@google.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Paolo Abeni authored
Merge tag 'linux-can-next-for-6.9-20240304' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2024-03-04 this is a pull request of 4 patches for net-next/master. The 1st patch is by Jimmy Assarsson and adds support for the Leaf v3 to the kvaser_usb driver. Martin Jocić's patch targets the kvaser_pciefd driver and adds support for the Kvaser PCIe 8xCAN device. Followed by a patch by me that adds a missing a cpu_to_le32() to the gs_usb driver, the change is not critical as the assigned value is 0. The last patch is also by me and replaces a literal 256 with a proper define. linux-can-next-for-6.9-20240304 * tag 'linux-can-next-for-6.9-20240304' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: can: mcp251xfd: __mcp251xfd_get_berr_counter(): use CAN_BUS_OFF_THRESHOLD instead of open coding it can: gs_usb: gs_cmd_reset(): use cpu_to_le32() to assign mode can: kvaser_pciefd: Add support for Kvaser PCIe 8xCAN can: kvaser_usb: Add support for Leaf v3 ==================== Link: https://lore.kernel.org/r/20240304092051.3631481-1-mkl@pengutronix.deSigned-off-by:
-
Abhishek Chauhan authored
Bridge driver today has no support to forward the userspace timestamp packets and ends up resetting the timestamp. ETF qdisc checks the packet coming from userspace and encounters to be 0 thereby dropping time sensitive packets. These changes will allow userspace timestamps packets to be forwarded from the bridge to NIC drivers. Setting the same bit (mono_delivery_time) to avoid dropping of userspace tstamp packets in the forwarding path. Existing functionality of mono_delivery_time remains unaltered here, instead just extended with userspace tstamp support for bridge forwarding path. Signed-off-by:
Abhishek Chauhan <quic_abchauha@quicinc.com> Reviewed-by:
-
Paolo Abeni authored
Eric Dumazet says: ==================== net: gro: cleanups and fast path refinement Current GRO stack has a 'fast path' for a subset of drivers, users of napi_frags_skb(). With TCP zerocopy/direct uses, header split at receive is becoming more important, and GRO fast path is disabled. This series makes GRO (a bit) more efficient for almost all use cases. ==================== Link: https://lore.kernel.org/r/20240301193740.3436871-1-edumazet@google.comSigned-off-by:
-
Eric Dumazet authored
In tcp_gro_complete() : Moving the skb->inner_transport_header setting allows the compiler to reuse the previously loaded value of skb->transport_header. Caching skb_shinfo() avoids duplications as well. In tcp4_gro_complete(), doing a single change on skb_shinfo(skb)->gso_type also generates better code. Signed-off-by:
-
Eric Dumazet authored
Currently the so-called GRO fast path is only enabled for napi_frags_skb() callers. After the prior patch, we no longer have to clear frag0 whenever we pulled bytes to skb->head. We therefore can initialize frag0 to skb->data so that GRO fast path can be used in the following additional cases: - Drivers using header split (populating skb->data with headers, and having payload in one or more page fragments). - Drivers not using any page frag (entire packet is in skb->data) Add a likely() in skb_gro_may_pull() to help the compiler to generate better code if possible. Signed-off-by:
-
Eric Dumazet authored
Change skb_gro_network_header() to accept a const sk_buff and to no longer check if frag0 is NULL or not. This allows to remove skb_gro_frag0_invalidate() which is seen in profiles when header-split is enabled. sk_buff parameter is constified for skb_gro_header_fast(), inet_gro_compute_pseudo() and ip6_gro_compute_pseudo(). Signed-off-by:
-
Eric Dumazet authored
skb_gro_header_hard() is renamed to skb_gro_may_pull() to match the convention used by common helpers like pskb_may_pull(). This means the condition is inverted: if (skb_gro_header_hard(skb, hlen)) slow_path(); becomes: if (!skb_gro_may_pull(skb, hlen)) slow_path(); Signed-off-by:
-
Paolo Abeni authored
says: ==================== MT7530 DSA Subdriver Improvements Act III This is the third patch series with the goal of simplifying the MT7530 DSA subdriver and improving support for MT7530, MT7531, and the switch on the MT7988 SoC. I have done a simple ping test to confirm basic communication on all switch ports on MCM and standalone MT7530, and MT7531 switch with this patch series applied. MT7621 Unielec, MCM MT7530: rgmii-only-gmac0-mt7621-unielec-u7621-06-16m.dtb gmac0-and-gmac1-mt7621-unielec-u7621-06-16m.dtb tftpboot 0x80008000 mips-uzImage.bin; tftpboot 0x83000000 mips-rootfs.cpio.uboot; tftpboot 0x83f00000 $dtb; bootm 0x80008000 0x83000000 0x83f00000 MT7622 Bananapi, MT7531: gmac0-and-gmac1-mt7622-bananapi-bpi-r64.dtb tftpboot 0x40000000 arm64-Image; tftpboot 0x45000000 arm64-rootfs.cpio.uboot; tftpboot 0x4a000000 $dtb; booti 0x40000000 0x45000000 0x4a000000 MT7623 Bananapi, standalone MT7530: rgmii-only-gmac0-mt7623n-bananapi-bpi-r2.dtb gmac0-and-gmac1-mt7623n-bananapi-bpi-r2.dtb tftpboot 0x80008000 arm-zImage; tftpboot 0x83000000 arm-rootfs.cpio.uboot; tftpboot 0x83f00000 $dtb; bootz 0x80008000 0x83000000 0x83f00000 This patch series is the continuation of the patch series linked below. https://lore.kernel.org/r/20230522121532.86610-1-arinc.unal@arinc9.comSigned-off-by:
Arınç ÜNAL <arinc.unal@arinc9.com> --- Changes in v3: - Patch 8 - Explain properly the behaviour of setting link down on all ports at setup. - Split the changes for simplifying the link settings operations out to another patch. - Link to v2: https://lore.kernel.org/r/20240216-for-netnext-mt7530-improvements-3-v2-0-094cae3ff23b@arinc9.com Changes in v2: - Patch 8 - Use a single mt7530_rmw() instead of two mt7530_clear() and mt7530_set() commands. - Link to v1: https://lore.kernel.org/r/20240208-for-netnext-mt7530-improvements-3-v1-0-d7c1cfd502ca@arinc9.com ==================== Link: https://lore.kernel.org/r/20240301-for-netnext-mt7530-improvements-3-v3-0-449f4f166454@arinc9.comSigned-off-by:
-
Arınç ÜNAL authored
The "MT7621 Giga Switch Programming Guide v0.3", "MT7531 Reference Manual for Development Board v1.0", and "MT7988A Wi-Fi 7 Generation Router Platform: Datasheet (Open Version) v0.1" documents show that these bits are enabled at reset: PMCR_IFG_XMIT(1) (not part of PMCR_LINK_SETTINGS_MASK) PMCR_MAC_MODE (not part of PMCR_LINK_SETTINGS_MASK) PMCR_TX_EN PMCR_RX_EN PMCR_BACKOFF_EN (not part of PMCR_LINK_SETTINGS_MASK) PMCR_BACKPR_EN (not part of PMCR_LINK_SETTINGS_MASK) PMCR_TX_FC_EN PMCR_RX_FC_EN These bits also don't exist on the MT7530_PMCR_P(6) register of the switch on the MT7988 SoC: PMCR_IFG_XMIT() PMCR_MAC_MODE PMCR_BACKOFF_EN PMCR_BACKPR_EN Remove the setting of the bits not part of PMCR_LINK_SETTINGS_MASK on phylink_mac_config as they're already set. The bit for setting the port on force mode is already done on mt7530_setup() and mt7531_setup_common(). So get rid of PMCR_FORCE_MODE_ID() which helped determine which bit to use for the switch model. Signed-off-by:
-
