- 03 Jun, 2024 3 commits
-
-
David S. Miller authored
Guangguan Wang says: ==================== net/smc: Change the upper boundary of SMC-R's snd_buf and rcv_buf to 512MB SMCR_RMBE_SIZES is the upper boundary of SMC-R's snd_buf and rcv_buf. The maximum bytes of snd_buf and rcv_buf can be calculated by 2^SMCR_ RMBE_SIZES * 16KB. SMCR_RMBE_SIZES = 5 means the upper boundary is 512KB. TCP's snd_buf and rcv_buf max size is configured by net.ipv4.tcp_w/rmem[2] whose default value is 4MB or 6MB, is much larger than SMC-R's upper boundary. In some scenarios, such as Recommendation System, the communication pattern is mainly large size send/recv, where the size of snd_buf and rcv_buf greatly affects performance. Due to the upper boundary disadvantage, SMC-R performs poor than TCP in those scenarios. So it is time to enlarge the upper boundary size of SMC-R's snd_buf and rcv_buf, so that the SMC-R's snd_buf and rcv_buf can be configured to larger size for performance gain in such scenarios. The SMC-R rcv_buf's size will be transferred to peer by the field rmbe_size in clc accept and confirm message. The length of the field rmbe_size is four bits, which means the maximum value of SMCR_RMBE_SIZES is 15. In case of frequently adjusting the value of SMCR_RMBE_SIZES in different scenarios, set the value of SMCR_RMBE_SIZES to the maximum value 15, which means the upper boundary of SMC-R's snd_buf and rcv_buf is 512MB. As the real memory usage is determined by the value of net.smc.w/rmem, not by the upper boundary, set the value of SMCR_RMBE_SIZES to the maximum value has no side affects. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Guangguan Wang authored
SMCR_RMBE_SIZES is the upper boundary of SMC-R's snd_buf and rcv_buf. The maximum bytes of snd_buf and rcv_buf can be calculated by 2^SMCR_ RMBE_SIZES * 16KB. SMCR_RMBE_SIZES = 5 means the upper boundary is 512KB. TCP's snd_buf and rcv_buf max size is configured by net.ipv4.tcp_w/rmem[2] whose default value is 4MB or 6MB, is much larger than SMC-R's upper boundary. In some scenarios, such as Recommendation System, the communication pattern is mainly large size send/recv, where the size of snd_buf and rcv_buf greatly affects performance. Due to the upper boundary disadvantage, SMC-R performs poor than TCP in those scenarios. So it is time to enlarge the upper boundary size of SMC-R's snd_buf and rcv_buf, so that the SMC-R's snd_buf and rcv_buf can be configured to larger size for performance gain in such scenarios. The SMC-R rcv_buf's size will be transferred to peer by the field rmbe_size in clc accept and confirm message. The length of the field rmbe_size is four bits, which means the maximum value of SMCR_RMBE_SIZES is 15. In case of frequently adjusting the value of SMCR_RMBE_SIZES in different scenarios, set the value of SMCR_RMBE_SIZES to the maximum value 15, which means the upper boundary of SMC-R's snd_buf and rcv_buf is 512MB. As the real memory usage is determined by the value of net.smc.w/rmem, not by the upper boundary, set the value of SMCR_RMBE_SIZES to the maximum value has no side affects. Signed-off-by:
Guangguan Wang <guangguan.wang@linux.alibaba.com> Co-developed-by:
Wen Gu <guwen@linux.alibaba.com> Signed-off-by:
-
Guangguan Wang authored
SG_MAX_SINGLE_ALLOC is used to limit maximum number of entries that will be allocated in one piece of scatterlist. When the entries of scatterlist exceeds SG_MAX_SINGLE_ALLOC, sg chain will be used. From commit 7c703e54 ("arch: switch the default on ARCH_HAS_SG_CHAIN"), we can know that the macro CONFIG_ARCH_NO_SG_CHAIN is used to identify whether sg chain is supported. So, SMC-R's rmb buffer should be limited by SG_MAX_SINGLE_ALLOC only when the macro CONFIG_ARCH_NO_SG_CHAIN is defined. Fixes: a3fe3d01 ("net/smc: introduce sg-logic for RMBs") Signed-off-by:
-
- 01 Jun, 2024 31 commits
-
-
Kuniyuki Iwashima authored
When splice() support was added in commit 2b514574 ("net: af_unix: implement splice for stream af_unix sockets"), we had to release unix_sk(sk)->readlock (current iolock) before calling splice_to_pipe(). Due to the unlock, commit 73ed5d25 ("af-unix: fix use-after-free with concurrent readers while splicing") added a safeguard in unix_stream_read_generic(); we had to bump the skb refcount before calling ->recv_actor() and then check if the skb was consumed by a concurrent reader. However, the pipe side locking was refactored, and since commit 25869262 ("skb_splice_bits(): get rid of callback"), we can call splice_to_pipe() without releasing unix_sk(sk)->iolock. Now, the skb is always alive after the ->recv_actor() callback, so let's remove the unnecessary drop_skb logic. This is mostly the revert of commit 73ed5d25 ("af-unix: fix use-after-free with concurrent readers while splicing"). Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://lore.kernel.org/r/20240529144648.68591-1-kuniyu@amazon.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Merge branch 'lan78xx-enable-125-mhz-clk-and-auto-speed-configuration-for-lan7801-if-no-eeprom-is-detected' Rengarajan says: ==================== lan78xx: Enable 125 MHz CLK and Auto Speed configuration for LAN7801 if NO EEPROM is detected This patch series adds the support for 125 MHz clock, Auto speed and auto duplex configuration for LAN7801 in the absence of EEPROM. ==================== Link: https://lore.kernel.org/r/20240529140256.1849764-1-rengarajan.s@microchip.comSigned-off-by:
-
Rengarajan S authored
Enabled ASD/ADD configuration for LAN7801 in the absence of EEPROM. After the lite reset these contents go back to defaults where ASD/ ADD is disabled. The check is already available for LAN7800. Reviewed-by:
Simon Horman <horms@kernel.org> Signed-off-by:
Rengarajan S <rengarajan.s@microchip.com> Link: https://lore.kernel.org/r/20240529140256.1849764-3-rengarajan.s@microchip.comSigned-off-by:
-
Rengarajan S authored
The 125MHz and 25MHz clock configurations are enabled in the initialization regardless of EEPROM (125MHz is needed for RGMII 1000Mbps operation). After a lite reset (lan78xx_reset), these contents go back to defaults(all 0, so no 125MHz or 25MHz clock). Reviewed-by:
-
Jakub Kicinski authored
Linus Walleij says: ==================== net: ethernet: cortina: Use phylib for RX and TX pause This patch series switches the Cortina Gemini ethernet driver to use phylib to set up RX and TX pause for the PHY. v3: https://lore.kernel.org/r/20240513-gemini-ethernet-fix-tso-v3-0-b442540cc140@linaro.org v2: https://lore.kernel.org/r/20240511-gemini-ethernet-fix-tso-v2-0-2ed841574624@linaro.org v1: https://lore.kernel.org/r/20240509-gemini-ethernet-fix-tso-v1-0-10cd07b54d1c@linaro.org ==================== Link: https://lore.kernel.org/r/20240529-gemini-phylib-fixes-v4-0-16487ca4c2fe@linaro.orgSigned-off-by:
-
Linus Walleij authored
The Cortina Gemini ethernet can very well set up TX or RX pausing, so add this functionality to the driver in a .set_pauseparam() callback. Essentially just call down to phylib and let phylib deal with this, .adjust_link() will respect the setting from phylib. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20240529-gemini-phylib-fixes-v4-3-16487ca4c2fe@linaro.orgSigned-off-by:
-
Linus Walleij authored
Instead of directly poking into registers of the PHY, use the existing function to query phylib about this directly. Suggested-by:
-
Linus Walleij authored
The callback passed to of_phy_get_and_connect() in the Cortina Gemini driver is called "gmac_speed_set" which is archaic, rename it to "gmac_adjust_link" following the pattern of most other drivers. Reviewed-by:
-
Jakub Kicinski authored
Matteo Croce says: ==================== net: visibility of memory limits in netns Some programs need to know the size of the network buffers to operate correctly, export the following sysctls read-only in network namespaces: - net.core.rmem_default - net.core.rmem_max - net.core.wmem_default - net.core.wmem_max ==================== Link: https://lore.kernel.org/r/20240530232722.45255-1-technoboy85@gmail.comSigned-off-by:
-
Matteo Croce authored
Add a selftest which checks that the sysctl is present in a netns, that the value is read from the init one, and that it's readonly. Signed-off-by:
Matteo Croce <teknoraver@meta.com> Link: https://lore.kernel.org/r/20240530232722.45255-3-technoboy85@gmail.comSigned-off-by:
-
Matteo Croce authored
The following sysctl are global and can't be read from a netns: net.core.rmem_default net.core.rmem_max net.core.wmem_default net.core.wmem_max Make the following sysctl parameters available readonly from within a network namespace, allowing a container to read them. Signed-off-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
Shakeel Butt <shakeel.butt@linux.dev> Link: https://lore.kernel.org/r/20240530232722.45255-2-technoboy85@gmail.comSigned-off-by:
-
Vadim Fedorenko authored
The ethtool_ts_stats structure was introduced earlier this year. Now it's time to support this group of counters in more drivers. This patch adds support to bnxt driver. Signed-off-by:
Vadim Fedorenko <vadfed@meta.com> Reviewed-by:
Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20240530204751.99636-1-vadfed@meta.comSigned-off-by:
-
Jakub Kicinski authored
Jacob Keller says: ==================== ice: Introduce ETH56G PHY model for E825C products E825C products have a different PHY model than E822, E823 and E810 products. This PHY is ETH56G and its support is necessary to have functional PTP stack for E825C products. This series refactors the ice driver to add support for the new PHY model. Karol introduces the ice_ptp_hw structure. This is used to replace some hard-coded values relating to the PHY quad and port numbers, as well as to hold the phy_model type. Jacob refactors the driver code that converts between the ice_ptp_tmr_cmd enumeration and hardware register values to better re-use logic and reduce duplication when introducing another PHY type. Sergey introduces functions to help enable and disable the Tx timestamp interrupts. This makes the ice_ptp.c code more generic and encapsulates the PHY specifics into ice_ptp_hw.c Karol introduces helper functions to clear the valid bits for Tx and Rx timestamps. This enables informing hardware to discard stale timestamps after performing clock operations. Sergey moves the Clock Generation Unit (CGU) logic out of the E822 specific area of the ice_ptp_hw.c file as it will be re-used for other device PHY models. Jacob introduces a helper function for obtaining the base increment values, moving this logic out of ice_ptp.c and into the ice_ptp_hw.c file to better encapsulate hardware differences. Sergey builds on these refactors to introduce the new ETH56G PHY model used by the E825C products. This includes introducing the required helpers, constants, and PHY model checks. Karol simplifies the CGU logic by using anonymous structures, dropping an unnecessary ".field" name for accessing the CGU data. Michal Michalik updates the CGU logic to support the E825C hardware, ensuring that the clock generation is configured properly. Grzegorz Nitka adds support to read the NAC topology data from the device. This is in preparation for supporting devices which combine two NACs together, connecting all ports to the same clock source. This enables the driver to determine if its operating on such a device, or if its operating on the standard 1-NAC configuration. Grzsecgorz Nitka adjusts the PTP initialization to prepare for the 2x50G E825C devices, introducing special mapping for the PHY ports to prepare for support of the 2-NAC devices. With this, the ice driver is capable of handling PTP for the single-NAC E825C devices. Complete support for the 2-NAC devices requirs some work on how the ports connect to the clock owner. During review of this work, it was pointed out that our existing use of auxiliary bus is disliked, and Jiri requested that we change it. We are currently working on developing a replacement solution for the auxiliary bus implementation and have dropped the relevant changes out of this series. A future series will refactor the port to clock connection, at which time we will finish the support for 2-NAC E825C devices. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> ==================== Link: https://lore.kernel.org/r/20240528-next-2024-05-28-ptp-refactors-v1-0-c082739bb6f6@intel.comSigned-off-by:
-
Grzegorz Nitka authored
>From FW/HW perspective, 2 port topology in E825C devices requires merging of 2 port mapping internally and breakout mapping externally. As a consequence, it requires different port numbering from PTP code perspective. For that topology, pf_id can not be used to index PTP ports. Even if the 2nd port is identified as port with pf_id = 1, all PHY operations need to be performed as it was port 2. Thus, special mapping is needed for the 2nd port. This change adds detection of 2x50G topology and applies 'custom' mapping on the 2nd port. Signed-off-by:
Grzegorz Nitka <grzegorz.nitka@intel.com> Reviewed-by:
Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Signed-off-by:
Karol Kolacinski <karol.kolacinski@intel.com> Tested-by:
Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> Signed-off-by:
-
Grzegorz Nitka authored
Add new device capability ICE_AQC_CAPS_NAC_TOPOLOGY which allows to determine the mode of operation (1 or 2 NAC). Define a new structure to store data from new capability and corresponding parser code. Co-developed-by:
Prathisna Padmasanan <prathisna.padmasanan@intel.com> Signed-off-by:
Pawel Kaminski <pawel.kaminski@intel.com> Reviewed-by:
Mateusz Polchlopek <mateusz.polchlopek@intel.com> Reviewed-by:
Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by:
-
Michal Michalik authored
The CGU layout of E825-C is a little different than E822/E823. Add support the new hardware adding relevant functions. Signed-off-by:
Michal Michalik <michal.michalik@intel.com> Reviewed-by:
-
Karol Kolacinski authored
Simplify the code by using anonymous struct in CGU registers instead of naming each structure 'field'. Suggested-by:
-
Sergey Temerkhanov authored
E825C products feature a new PHY model - ETH56G. Introduces all necessary PHY definitions, functions etc. for ETH56G PHY, analogous to E82X and E810 ones with addition of a few HW-specific functionalities for ETH56G like one-step timestamping. It ensures correct PTP initialization and operation for E825C products. Co-developed-by:
Sergey Temerkhanov <sergey.temerkhanov@intel.com> Reviewed-by:
-
Jacob Keller authored
Add a new helper for getting base clock increment value for specific HW. Reviewed-by:
-
Sergey Temerkhanov authored
Move CGU block to the beginning of ice_ptp_hw.c Signed-off-by:
-
Karol Kolacinski authored
Add a possibility to mark all transmitted/received timestamps as invalid by clearing PHY OFFSET_READY registers. Reviewed-by:
-
Sergey Temerkhanov authored
Introduce functions enabling/disabling Tx TS interrupts for the E822 and ETH56G PHYs Signed-off-by:
-
Jacob Keller authored
Multiple places in the driver code need to convert enum ice_ptp_tmr_cmd values into register bits for both the main timer and the PHY port timers. The main MAC register has one bit scheme for timer commands, while the PHY commands use a different scheme. The E810 and E830 devices use the same scheme for port commands as used for the main timer. However, E822 and ETH56G hardware has a separate scheme used by the PHY. Introduce helper functions to convert the timer command enumeration into the register values, reducing some code duplication, and making it easier to later refactor the individual port write commands. Reviewed-by:
-
Karol Kolacinski authored
Create new ice_ptp_hw struct and use it for all HW and PTP-related fields from struct ice_hw. Replace definitions with struct fields, which values are set accordingly to a specific device. Reviewed-by:
-
Abhishek Chauhan authored
Currently there are no strict checks while setting SO_TXTIME from userspace. With the recent development in skb->tstamp_type clockid with unsupported clocks results in warn_on_once, which causes unnecessary aborts in some systems which enables panic on warns. Add validation in setsockopt to support only CLOCK_REALTIME, CLOCK_MONOTONIC and CLOCK_TAI to be set from userspace. Link: https://lore.kernel.org/netdev/bc037db4-58bb-4861-ac31-a361a93841d3@linux.dev/ Link: https://lore.kernel.org/lkml/6bdba7b6-fd22-4ea5-a356-12268674def1@quicinc.com/ Fixes: 1693c5db ("net: Add additional bit to support clockid_t timestamp type") Reported-by: syzbot+d7b227731ec589e7f4f0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d7b227731ec589e7f4f0 Reported-by: syzbot+30a35a2e9c5067cc43fa@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=30a35a2e9c5067cc43faSigned-off-by:
Abhishek Chauhan <quic_abchauha@quicinc.com> Acked-by:
Martin KaFai Lau <martin.lau@kernel.org> Reviewed-by:
Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20240529183130.1717083-1-quic_abchauha@quicinc.comSigned-off-by:
-
Jakub Kicinski authored
Matthieu Baerts says: ==================== doc: mptcp: new general doc and fixes A general documentation about MPTCP was missing since its introduction in v5.6. The last patch adds a new 'mptcp' page in the 'networking' documentation. The first patch is a fix for a missing sysctl entry introduced in v6.10 rc0, and the second one reorder the sysctl entries. Signed-off-by:
Matthieu Baerts (NGI0) <matttbe@kernel.org> ==================== v2: https://lore.kernel.org/r/20240528-upstream-net-20240520-mptcp-doc-v2-0-47f2d5bc2ef3@kernel.org v1: https://lore.kernel.org/r/20240520-upstream-net-20240520-mptcp-doc-v1-0-e3ad294382cb@kernel.org Link: https://lore.kernel.org/r/20240530-upstream-net-20240520-mptcp-doc-v3-0-e94cdd9f2673@kernel.orgSigned-off-by:
-
Matthieu Baerts (NGI0) authored
A general documentation about MPTCP was missing since its introduction in v5.6. Most of what is there comes from our recently updated mptcp.dev website, with additional links to resources from the kernel documentation. This is a first version, mainly targeting app developers and users. Link: https://www.mptcp.devReviewed-by:
Mat Martineau <martineau@kernel.org> Signed-off-by:
-
Matthieu Baerts (NGI0) authored
Similar to what is done in other 'sysctl' pages: it looks clearer from a readability perspective. This might cause troubles in the short/mid-term with the backports, but by not putting new entries at the end, this can help to reduce conflicts in case of backports in the long term. We don't change the information here too often, so it looks OK to do that. Reviewed-by:
-
Matthieu Baerts (NGI0) authored
This sysctl knob has been added recently, but the documentation has not been updated. This knob is used to show the available schedulers choices that are registered, similar to 'net.ipv4.tcp_available_congestion_control'. Fixes: 73c900aa ("mptcp: add net.mptcp.available_schedulers") Reviewed-by:
-
Thorsten Blum authored
Use void __iomem pointers as parameters for mcf_insw() and mcf_outsw() to align with the parameter types of readw() and writew() to fix the following warnings reported by kernel test robot: drivers/net/ethernet/smsc/smc91x.c:590:9: sparse: warning: incorrect type in argument 1 (different address spaces) drivers/net/ethernet/smsc/smc91x.c:590:9: sparse: expected void *a drivers/net/ethernet/smsc/smc91x.c:590:9: sparse: got void [noderef] __iomem * drivers/net/ethernet/smsc/smc91x.c:590:9: sparse: warning: incorrect type in argument 1 (different address spaces) drivers/net/ethernet/smsc/smc91x.c:590:9: sparse: expected void *a drivers/net/ethernet/smsc/smc91x.c:590:9: sparse: got void [noderef] __iomem * drivers/net/ethernet/smsc/smc91x.c:590:9: sparse: warning: incorrect type in argument 1 (different address spaces) drivers/net/ethernet/smsc/smc91x.c:590:9: sparse: expected void *a drivers/net/ethernet/smsc/smc91x.c:590:9: sparse: got void [noderef] __iomem * drivers/net/ethernet/smsc/smc91x.c:483:17: sparse: warning: incorrect type in argument 1 (different address spaces) drivers/net/ethernet/smsc/smc91x.c:483:17: sparse: expected void *a drivers/net/ethernet/smsc/smc91x.c:483:17: sparse: got void [noderef] __iomem * Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202405160853.3qyaSj8w-lkp@intel.com/Acked-by:
Nicolas Pitre <nico@fluxnic.net> Reviewed-by:
Thorsten Blum <thorsten.blum@toblux.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20240529143859.108201-4-thorsten.blum@toblux.comSigned-off-by:
-
Jakub Kicinski authored
mlx5 has a dedicated queue for PTP packets. Clarify that this sort of queues can also be accounted towards the base. Reviewed-by:
Joe Damato <jdamato@fastly.com> Link: https://lore.kernel.org/r/20240529162922.3690698-1-kuba@kernel.orgSigned-off-by:
-
- 31 May, 2024 6 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
Cross-merge networking fixes after downstream PR. Conflicts: drivers/net/ethernet/ti/icssg/icssg_classifier.c abd5576b ("net: ti: icssg-prueth: Add support for ICSSG switch firmware") 56a5cf53 ("net: ti: icssg-prueth: Fix start counter for ft1 filter") https://lore.kernel.org/all/20240531123822.3bb7eadf@canb.auug.org.au/ No other adjacent changes. Signed-off-by:
-
Jakub Kicinski authored
Folks working on a C++ codegen would like to reuse the attribute helpers directly. Add the few necessary casts, it's not too ugly. Reviewed-by:
Donald Hunter <donald.hunter@gmail.com> Reviewed-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20240529192031.3785761-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Russell King says: ==================== net: phylink: rearrange ovr_an_inband support This series addresses the use of the ovr_an_inband flag, which is used by two drivers to indicate to phylink that they wish to use inband mode without firmware specifying inband mode. The issue with ovr_an_inband is that it overrides not only PHY mode, but also fixed-link mode. Both of the drivers that set this flag contain code to detect when fixed-link mode will be used, and then either avoid setting it or explicitly clear the flag. This is wasteful when phylink already knows this. Therefore, the approach taken in this patch set is to replace the ovr_an_inband flag with a default_an_inband flag which means that phylink defaults to MLO_AN_INBAND instead of MLO_AN_PHY, and will allow that default to be overriden if firmware specifies a fixed-link. This allows users of ovr_an_inband to be simplified. What's more is this requires minimal changes in phylink to allow this new mode of operation. This series changes phylink, and also updates the two drivers (fman_memac and stmmac), and then removes the unnecessary complexity from the drivers. This series may depend on the stmmac cleanup series I've posted earlier - this is something I have not checked, but I currently have these patches on top of that series. ==================== Link: https://lore.kernel.org/r/ZlctinnTT8Xhemsm@shell.armlinux.org.ukSigned-off-by:
-
Russell King (Oracle) authored
With the new default_an_inband functionality in phylink, there is no need to check for a fixed link when this flag is set, since a fixed link will now override default_an_inband. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by:
Andrew Halaney <ahalaney@redhat.com> Link: https://lore.kernel.org/r/E1sCJNB-00EcrJ-7L@rmk-PC.armlinux.org.ukSigned-off-by:
-
Russell King (Oracle) authored
Rename xpcs_an_inband to default_an_inband to reflect the change in phylink and its changed functionality. Signed-off-by:
-
Russell King (Oracle) authored
Since default_an_inband can be overriden by a fixed-link specification, there is no need for memac to be checking for this before setting default_an_inband. Remove this code and update the comment. Signed-off-by:
Sean Anderson <sean.anderson@seco.com> Reviewed-by:
-
