- 11 Sep, 2024 12 commits
-
-
Michael Chan authored
bnxt_check_rings() is called to ensure that we have the hardware ring resources before committing to reinitialize with the new number of rings. MSIX vectors are never checked at this point, because up until recently we must first disable MSIX before we can allocate the new set of MSIX vectors. Now that we support dynamic MSIX allocation, check to make sure we can dynamically allocate the new MSIX vectors as the last step in bnxt_check_rings() if dynamic MSIX is supported. For example, the IOMMU group may limit the number of MSIX vectors for the device. With this patch, the ring change will fail more gracefully when there is not enough MSIX vectors. It is also better to move bnxt_check_rings() to be called as the last step when changing ethtool rings. Reviewed-by:
Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by:
Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Reviewed-by:
Andy Gospodarek <andrew.gospodarek@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240909202737.93852-3-michael.chan@broadcom.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Michael Chan authored
If RocE is supported on the device, set the number of RoCE MSIX vectors to the number of online CPUs + 1 and capped at these maximums: VF: 2 NPAR: 5 PF: 64 For the PF, the maximum is now increased from the previous value of 9 to get better performance for kernel applications. Remove the unnecessary check for BNXT_FLAG_ROCE_CAP. bnxt_set_dflt_ulp_msix() will only be called if the flag is set. Reviewed-by:
-
Rob Herring (Arm) authored
The "amlogic,tx-delay-ns" property schema has unnecessary type reference as it's a standard unit suffix, and the constraints are in freeform text rather than schema. Signed-off-by:
Rob Herring (Arm) <robh@kernel.org> Reviewed-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://patch.msgid.link/20240909172342.487675-2-robh@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Sean Anderson says: ==================== net: xilinx: axienet: Partial checksum offload improvements Partial checksum offload is not always used when it could be. Enable it in more cases. ==================== Link: https://patch.msgid.link/20240909161016.1149119-1-sean.anderson@linux.devSigned-off-by:
-
Sean Anderson authored
The partial rx checksum feature computes a checksum over the entire packet, regardless of the L3 protocol. Remove the check for IPv4. Additionally, testing with csum.py (from kselftests) shows no anomalies with 64-byte packets, so we can remove that check as well. Signed-off-by:
Sean Anderson <sean.anderson@linux.dev> Reviewed-by:
-
Sean Anderson authored
When it is supported by hardware, we enable receive checksum offload unconditionally. Update features to reflect this. Signed-off-by:
-
Sean Anderson authored
Partial tx chechsumming is completely generic and does not depend on the L3/L4 protocol. Signal this to the net subsystem by enabling the more-generic offload feature (instead of restricting ourselves to TCP/UDP over IPv4 checksumming only like is necessary with full checksumming). Signed-off-by:
-
Sean Anderson authored
These variables are set but never used. Remove them. Signed-off-by:
Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Link: https://patch.msgid.link/20240909161016.1149119-2-sean.anderson@linux.devSigned-off-by:
-
Colin Ian King authored
There is a spelling mistake in the struct field tx_underun, rename it to tx_underrun. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Reviewed-by:
-
Colin Ian King authored
There is a spelling mistake in the struct field tx_underun, rename it to tx_underrun. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/20240909140021.64884-1-colin.i.king@gmail.comSigned-off-by:
-
Dave Taht authored
sch_cake uses a cache of the first 16 values of the inverse square root calculation for the Cobalt AQM to save some cycles on the fast path. This cache is populated when the qdisc is first loaded, but there's really no reason why it can't just be pre-populated. So change it to be pre-populated with constants, which also makes it possible to constify it. This gives a modest space saving for the module (not counting debug data): .text: -224 bytes .rodata: +80 bytes .bss: -64 bytes Total: -192 bytes Signed-off-by:
Dave Taht <dave.taht@gmail.com> [ fixed up comment, rewrote commit message ] Signed-off-by:
Toke Høiland-Jørgensen <toke@redhat.com> Link: https://patch.msgid.link/20240909091630.22177-1-toke@redhat.comSigned-off-by:
-
Pieter Van Trappen authored
Remove magic number 7 by introducing a GENMASK macro instead. Remove magic number 0x80 by using the BIT macro instead. Signed-off-by:
Pieter Van Trappen <pieter.van.trappen@cern.ch> Reviewed-by:
Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20240909134301.75448-1-vtpieter@gmail.comSigned-off-by:
-
- 10 Sep, 2024 28 commits
-
-
Jakub Kicinski authored
Jason Xing says: ==================== net-timestamp: introduce a flag to filter out rx software and hardware report When one socket is set SOF_TIMESTAMPING_RX_SOFTWARE which means the whole system turns on the netstamp_needed_key button, other sockets that only have SOF_TIMESTAMPING_SOFTWARE will be affected and then print the rx timestamp information even without setting SOF_TIMESTAMPING_RX_SOFTWARE generation flag. How to solve it without breaking users? We introduce a new flag named SOF_TIMESTAMPING_OPT_RX_FILTER. Using it together with SOF_TIMESTAMPING_SOFTWARE can stop reporting the rx software timestamp. Similarly, we also filter out the hardware case where one process enables the rx hardware generation flag, then another process only passing SOF_TIMESTAMPING_RAW_HARDWARE gets the timestamp. So we can set both SOF_TIMESTAMPING_RAW_HARDWARE and SOF_TIMESTAMPING_OPT_RX_FILTER to stop reporting rx hardware timestamp after this patch applied. v6: https://lore.kernel.org/20240906095640.77533-1-kerneljasonxing@gmail.com v5: https://lore.kernel.org/20240905071738.3725-1-kerneljasonxing@gmail.com v4: https://lore.kernel.org/20240830153751.86895-1-kerneljasonxing@gmail.com v3: https://lore.kernel.org/20240828160145.68805-1-kerneljasonxing@gmail.com v2: https://lore.kernel.org/20240825152440.93054-1-kerneljasonxing@gmail.com ==================== Link: https://patch.msgid.link/20240909015612.3856-1-kerneljasonxing@gmail.comSigned-off-by:
-
Jason Xing authored
Test a few possible cases where we use SOF_TIMESTAMPING_OPT_RX_FILTER with software or hardware report/generation flag. Signed-off-by:
Jason Xing <kernelxing@tencent.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20240909015612.3856-3-kerneljasonxing@gmail.comSigned-off-by:
-
Jason Xing authored
introduce a new flag SOF_TIMESTAMPING_OPT_RX_FILTER in the receive path. User can set it with SOF_TIMESTAMPING_SOFTWARE to filter out rx software timestamp report, especially after a process turns on netstamp_needed_key which can time stamp every incoming skb. Previously, we found out if an application starts first which turns on netstamp_needed_key, then another one only passing SOF_TIMESTAMPING_SOFTWARE could also get rx timestamp. Now we handle this case by introducing this new flag without breaking users. Quoting Willem to explain why we need the flag: "why a process would want to request software timestamp reporting, but not receive software timestamp generation. The only use I see is when the application does request SOF_TIMESTAMPING_SOFTWARE | SOF_TIMESTAMPING_TX_SOFTWARE." Similarly, this new flag could also be used for hardware case where we can set it with SOF_TIMESTAMPING_RAW_HARDWARE, then we won't receive hardware receive timestamp. Another thing about errqueue in this patch I have a few words to say: In this case, we need to handle the egress path carefully, or else reporting the tx timestamp will fail. Egress path and ingress path will finally call sock_recv_timestamp(). We have to distinguish them. Errqueue is a good indicator to reflect the flow direction. Suggested-by:
-
Jason Xing authored
SOF_TIMESTAMPING_RAW_HARDWARE is a report flag which passes the timestamps generated by either SOF_TIMESTAMPING_TX_HARDWARE or SOF_TIMESTAMPING_RX_HARDWARE to the userspace all the time. So let us revise the doc here. Link: https://lore.kernel.org/all/66d8c21d3042a_163d93294cb@willemb.c.googlers.com.notmuch/Suggested-by:
Willem de Bruijn <willemdebruijn.kernel@gmail.com> Reviewed-by:
-
Jakub Kicinski authored
Furong Xu says: ==================== net: stmmac: FPE via ethtool + tc Move the Frame Preemption(FPE) over to the new standard API which uses ethtool-mm/tc-mqprio/tc-taprio. ==================== Link: https://patch.msgid.link/cover.1725631883.git.0x1207@gmail.comSigned-off-by:
-
Furong Xu authored
ethtool --show-mm can get real-time state of FPE. fpe_irq_status logs should keep quiet. tc-taprio can always query driver state, delete unbalanced logs. Signed-off-by:
Furong Xu <0x1207@gmail.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/39943d7967f291674a97ef0572878aca273087e9.1725631883.git.0x1207@gmail.comSigned-off-by:
-
Furong Xu authored
tc-taprio can select whether traffic classes are express or preemptible. 0) tc qdisc add dev eth1 parent root handle 100 taprio \ num_tc 4 \ map 0 1 2 3 2 2 2 2 2 2 2 2 2 2 2 3 \ queues 1@0 1@1 1@2 1@3 \ base-time 1000000000 \ sched-entry S 03 10000000 \ sched-entry S 0e 10000000 \ flags 0x2 fp P E E E 1) After some traffic tests, MAC merge layer statistics are all good. Local device: [ { "ifname": "eth1", "pmac-enabled": true, "tx-enabled": true, "tx-active": true, "tx-min-frag-size": 60, "rx-min-frag-size": 60, "verify-enabled": true, "verify-time": 100, "max-verify-time": 128, "verify-status": "SUCCEEDED", "statistics": { "MACMergeFrameAssErrorCount": 0, "MACMergeFrameSmdErrorCount": 0, "MACMergeFrameAssOkCount": 0, "MACMergeFragCountRx": 0, "MACMergeFragCountTx": 17837, "MACMergeHoldCount": 18639 } } ] Remote device: [ { "ifname": "end1", "pmac-enabled": true, "tx-enabled": true, "tx-active": true, "tx-min-frag-size": 60, "rx-min-frag-size": 60, "verify-enabled": true, "verify-time": 100, "max-verify-time": 128, "verify-status": "SUCCEEDED", "statistics": { "MACMergeFrameAssErrorCount": 0, "MACMergeFrameSmdErrorCount": 0, "MACMergeFrameAssOkCount": 17189, "MACMergeFragCountRx": 17837, "MACMergeFragCountTx": 0, "MACMergeHoldCount": 0 } } ] Tested on DWMAC CORE 5.10a Signed-off-by: -
Furong Xu authored
tc-mqprio can select whether traffic classes are express or preemptible. After some traffic tests, MAC merge layer statistics are all good. Local device: ethtool --include-statistics --json --show-mm eth1 [ { "ifname": "eth1", "pmac-enabled": true, "tx-enabled": true, "tx-active": true, "tx-min-frag-size": 60, "rx-min-frag-size": 60, "verify-enabled": true, "verify-time": 100, "max-verify-time": 128, "verify-status": "SUCCEEDED", "statistics": { "MACMergeFrameAssErrorCount": 0, "MACMergeFrameSmdErrorCount": 0, "MACMergeFrameAssOkCount": 0, "MACMergeFragCountRx": 0, "MACMergeFragCountTx": 35105, "MACMergeHoldCount": 0 } } ] Remote device: ethtool --include-statistics --json --show-mm end1 [ { "ifname": "end1", "pmac-enabled": true, "tx-enabled": true, "tx-active": true, "tx-min-frag-size": 60, "rx-min-frag-size": 60, "verify-enabled": true, "verify-time": 100, "max-verify-time": 128, "verify-status": "SUCCEEDED", "statistics": { "MACMergeFrameAssErrorCount": 0, "MACMergeFrameSmdErrorCount": 0, "MACMergeFrameAssOkCount": 35105, "MACMergeFragCountRx": 35105, "MACMergeFragCountTx": 0, "MACMergeHoldCount": 0 } } ] Tested on DWMAC CORE 5.10a Signed-off-by: -
Furong Xu authored
Implement ethtool --show-mm and --set-mm callbacks. NIC up/down, link up/down, suspend/resume, kselftest-ethtool_mm, all tested okay. Signed-off-by:
-
Furong Xu authored
Drop driver defined stmmac_fpe_state, and switch to common ethtool_mm_verify_status for local TX verification status. Local side and remote side verification processes are completely independent. There is no reason at all to keep a local state and a remote state. Add a spinlock to avoid races among ISR, timer, link update and register configuration. This patch is based on Vladimir Oltean's proposal. Vladimir Oltean says: ==================== In the INITIAL state, the timer sends MPACKET_VERIFY. Eventually the stmmac_fpe_event_status() IRQ fires and advances the state to VERIFYING, then rearms the timer after verify_time ms. If a subsequent IRQ comes in and modifies the state to SUCCEEDED after getting MPACKET_RESPONSE, the timer sees this. It must enable the EFPE bit now. Otherwise, it decrements the verify_limit counter and tries again. Eventually it moves the status to FAILED, from which the IRQ cannot move it anywhere else, except for another stmmac_fpe_apply() call. ==================== Co-developed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Furong Xu authored
ethtool --set-mm can trigger FPE verification process by calling stmmac_fpe_send_mpacket, stmmac_fpe_handshake should be gone. Signed-off-by:
-
Furong Xu authored
By moving the fpe_cfg field to the stmmac_priv data, stmmac_fpe_cfg becomes platform-data eventually, instead of a run-time config. Suggested-by:
Serge Semin <fancer.lancer@gmail.com> Signed-off-by:
-
Alexander Dahl authored
Was slightly misleading before, because printed is pointer to fwnode, not to phy device, as placement in message suggested. Include header for dev_dbg() declaration while at it. Output before: [ +0.001247] mdio_bus f802c000.ethernet-ffffffff: registered phy 2612f00a fwnode at address 3 Output after: [ +0.001229] mdio_bus f802c000.ethernet-ffffffff: registered phy fwnode /ahb/apb/ethernet@f802c000/ethernet-phy@3 at address 3 Reviewed-by:Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Alexander Dahl <ada@thorsis.com> Link: https://patch.msgid.link/20240906062256.11289-1-ada@thorsis.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
D. Wythe authored
In commit 48b6190a ("net/smc: Limit SMC visits when handshake workqueue congested"), we introduce a mechanism to put constraint on SMC connections visit according to the pressure of SMC handshake process. At that time, we believed that controlling the feature through netlink was sufficient. However, most people have realized now that netlink is not convenient in container scenarios, and sysctl is a more suitable approach. In addition, since commit 462791bb ("net/smc: add sysctl interface for SMC") had introcuded smc_sysctl_net_init(), it is reasonable for us to initialize limit_smc_hs in it instead of initializing it in smc_pnet_net_int(). Signed-off-by:
D. Wythe <alibuda@linux.alibaba.com> Reviewed-by:
Wen Gu <guwen@linux.alibaba.com> Reviewed-by:
Jan Karcher <jaka@linux.ibm.com> Link: https://patch.msgid.link/1725590135-5631-1-git-send-email-alibuda@linux.alibaba.comSigned-off-by:
-
Lee Trager authored
This adds support to show firmware version information for both stored and running firmware versions. The version and commit is displayed separately to aid monitoring tools which only care about the version. Example output: # devlink dev info pci/0000:01:00.0: driver fbnic serial_number 88-25-08-ff-ff-01-50-92 versions: running: fw 24.07.15-017 fw.commit h999784ae9df0 fw.bootloader 24.07.10-000 fw.bootloader.commit hfef3ac835ce7 stored: fw 24.07.24-002 fw.commit hc9d14a68b3f2 fw.bootloader 24.07.22-000 fw.bootloader.commit h922f8493eb96 fw.undi 01.00.03-000 Signed-off-by:Lee Trager <lee@trager.us> Reviewed-by:
-
Paolo Abeni authored
Daniel Machon says: ==================== net: lan966x: use the newly introduced FDMA library This patch series is the second of a 2-part series [1], that adds a new common FDMA library for Microchip switch chips Sparx5 and lan966x. These chips share the same FDMA engine, and as such will benefit from a common library with a common implementation. This also has the benefit of removing a lot of open-coded bookkeeping and duplicate code for the two drivers. In this second series, the FDMA library will be taken into use by the lan966x switch driver. ################### # Example of use: # ################### - Initialize the rx and tx fdma structs with values for: number of DCB's, number of DB's, channel ID, DB size (data buffer size), and total size of the requested memory. Also provide two callbacks: nextptr_cb() and dataptr_cb() for getting the nextptr and dataptr. - Allocate memory using fdma_alloc_phys() or fdma_alloc_coherent(). - Initialize the DCB's with fdma_dcb_init(). - Add new DCB's with fdma_dcb_add(). - Free memory with fdma_free_phys() or fdma_free_coherent(). ##################### # Patch breakdown: # ##################### Patch #1: select FDMA library for lan966x. Patch #2: includes the fdma_api.h header and removes old symbols. Patch #3: replaces old rx and tx variables with equivalent ones from the fdma struct. Only the variables that can be changed without breaking traffic is changed in this patch. Patch #4: uses the library for allocation of rx buffers. This requires quite a bit of refactoring in this single patch. Patch #5: uses the library for adding DCB's in the rx path. Patch #6: uses the library for freeing rx buffers. Patch #7: uses the library for allocation of tx buffers. This requires quite a bit of refactoring in this single patch. Patch #8: uses the library for adding DCB's in the tx path. Patch #9: uses the library helpers in the tx path. Patch #10: ditch last_in_use variable and use library instead. Patch #11: uses library helpers throughout. Patch #12: refactor lan966x_fdma_reload() function. [1] https://lore.kernel.org/netdev/20240902-fdma-sparx5-v1-0-1e7d5e5a9f34@microchip.com/Signed-off-by:Daniel Machon <daniel.machon@microchip.com> ==================== Link: https://patch.msgid.link/20240905-fdma-lan966x-v1-0-e083f8620165@microchip.comSigned-off-by:
-
Daniel Machon authored
Now that we store everything in the fdma structs, refactor lan966x_fdma_reload() to store and restore the entire struct. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Daniel Machon authored
The library provides helpers for a number of DCB and DB operations. Use these throughout the code and remove the old ones. Signed-off-by:
-
Daniel Machon authored
This variable is used in the tx path to determine the last used DCB. The library has the variable last_dcb for the exact same purpose. Ditch the last_in_use variable throughout. Signed-off-by:
-
Daniel Machon authored
The library has the helper fdma_free_phys() for freeing physical FDMA memory. Use it in the exit path. Signed-off-by:
-
Daniel Machon authored
Use the fdma_dcb_add() function to add DCB's in the tx path. This gets rid of the open-coding of nextptr and dataptr handling and leaves it to the library. Signed-off-by:
-
Daniel Machon authored
Use the two functions: fdma_alloc_phys() and fdma_dcb_init() for rx buffer allocation and use the new buffers throughout. In order to replace the old buffers with the new ones, we have to do the following refactoring: - use fdma_alloc_phys() and fdma_dcb_init() - replace the variables: tx->dma, tx->dcbs and tx->curr_entry with the equivalents from the FDMA struct. - add lan966x_fdma_tx_dataptr_cb callback for obtaining the dataptr. - Initialize FDMA struct values. Signed-off-by: -
Daniel Machon authored
The library has the helper fdma_free_phys() for freeing physical FDMA memory. Use it in the exit path. Signed-off-by:
-
Daniel Machon authored
Use the fdma_dcb_add() function to add DCB's in the rx path. This gets rid of the open-coding of nextptr and dataptr handling and the functions for adding DCB's. Signed-off-by:
-
Daniel Machon authored
Use the two functions: fdma_alloc_phys() and fdma_dcb_init() for rx buffer allocation and use the new buffers throughout. In order to replace the old buffers with the new ones, we have to do the following refactoring: - use fdma_alloc_phys() and fdma_dcb_init() - replace the variables: rx->dma, rx->dcbs and rx->last_entry with the equivalents from the FDMA struct. - make use of fdma->db_size for rx buffer size. - add lan966x_fdma_rx_dataptr_cb callback for obtaining the dataptr. - Initialize FDMA struct values. Signed-off-by: -
Daniel Machon authored
Replace the old rx and tx variables: channel_id, FDMA_DCB_MAX, FDMA_RX_DCB_MAX_DBS, FDMA_TX_DCB_MAX_DBS, dcb_index and db_index with the equivalents from the FDMA rx and tx structs. These variables are not entangled in any buffer allocation and can therefore be replaced in advance. Signed-off-by:
-
Daniel Machon authored
Include and use the new FDMA header, which now provides the required masks and bit offsets for operating on the DCB's and DB's. Signed-off-by:
-
Daniel Machon authored
Select the newly introduced FDMA library. Signed-off-by:
-
