- 30 Sep, 2022 40 commits
-
-
Maxim Mikityanskiy authored
Some commands use a flexible array after a common header. Add a macro to safely calculate the total input length of the command, detecting overflows and printing errors with specific values when such overflows happen. Signed-off-by:
Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Maxim Mikityanskiy authored
Currently, rq->mkey_be keeps a big-endian value of either the PA MKey (for legacy RQ, no address translation) or MTT MKey (for striding RQ, direct address translation). Striding RQ stores the same value in rq->umr_mkey in the native endianness. The next commit will make striding RQ use KSM MKey (indirect address translation) for the unaligned mode of XSK, which will require storing both KSM MKey and PA MKey in the RQ struct. This commit optimizes fields of mlx5e_rq: umr_mkey is removed (it's redundant), mkey_be always points to the PA MKey, and mpwqe.umr_mkey_be points to the MTT MKey (or to the KSM MKey, starting from the next commit). Signed-off-by:
-
Maxim Mikityanskiy authored
XSK RQs support striding RQ linear mode, but the stride size is always set to PAGE_SIZE. It may be larger than the XSK frame size, unnecessarily reducing the useful space in a WQE, but more importantly causing UMEM data corruption in certain cases. Normally, stride size bigger than XSK frame size is not a problem if the hardware enforces the MTU. However, traffic between vports skips the hardware MTU check, and oversized packets may be received. If an oversized packet is bigger than the XSK frame but not bigger than the stride, it will cause overwriting of the adjacent UMEM region. If the packet takes more than one stride, they can be recycled for reuse so it's not a problem when the XSK frame size matches the stride size. To reduce the impact of the above issue, attempt to use the MTT page size for striding RQ that matches the XSK frame size, allowing to safely use 2048-byte frames on an up-to-date firmware. Signed-off-by:
-
Maxim Mikityanskiy authored
This commit allows striding RQ to determine MTT page size at runtime, instead of sticking to the compile-time PAGE_SIZE. This functionality will be used by a following commit that adjusts the MTT page size to the XSK frame size. Stick with PAGE_SIZE for XSK on legacy RQ, as frag_stride is not used in data path, it only helps calculate how pages are partitioned into fragments, and PAGE_SIZE will ensure each fragment starts at the beginning of a new allocation unit (XSK frame). Signed-off-by:
-
Maxim Mikityanskiy authored
Drivers should be aware of the range of valid UMEM chunk sizes to be able to allocate their internal structures of an appropriate size. It will be used by mlx5e in the following patches. Signed-off-by:
-
Hongbin Wang authored
There should be no space before the comma Signed-off-by:
Hongbin Wang <wh_bin@126.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jianguo Zhang says: ==================== Mediatek ethernet patches for mt8188 Changes in v7: v7: 1) Add 'Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>' info in commit message of patch 'dt-bindings: net: snps,dwmac: add new property snps,clk-csr', 'arm64: dts: mediatek: mt2712e: Update the name of property 'clk_csr'' and 'net: stmmac: add a parse for new property 'snps,clk-csr''. v6: 1) Update commit message of patch 'dt-bindings: net: snps,dwmac: add new property snps,clk-csr' 2) Add a parse for new property 'snps,clk-csr' in patch 'net: stmmac: add a parse for new property 'snps,clk-csr'' v5: 1) Rename the property 'clk_csr' as 'snps,clk-csr' in binding file as Krzysztof Kozlowski'comment. 2) Add DTS patch 'arm64: dts: mediatek: mt2712e: Update the name of property 'clk_csr'' as Krzysztof Kozlowski'comment. 3) Add driver patch 'net: stmmac: Update the name of property 'clk_csr'' as Krzysztof Kozlowski'comment. v4: 1) Update the commit message of patch 'dt-bindings: net: snps,dwmac: add clk_csr property' as Krzysztof Kozlowski'comment. v3: 1) List the names of SoCs mt8188 and mt8195 in correct order as AngeloGioacchino Del Regno's comment. 2) Add patch version info as Krzysztof Kozlowski'comment. v2: 1) Delete patch 'stmmac: dwmac-mediatek: add support for mt8188' as Krzysztof Kozlowski's comment. 2) Update patch 'dt-bindings: net: mediatek-dwmac: add support for mt8188' as Krzysztof Kozlowski's comment. 3) Add clk_csr property to fix warning ('clk_csr' was unexpected) when runnig 'make dtbs_check'. v1: 1) Add ethernet driver entry for mt8188. 2) Add binding document for ethernet on mt8188. ==================== Signed-off-by: -
Jianguo Zhang authored
Parse new property 'snps,clk-csr' firstly because the new property is documented in binding file, if failed, fall back to old property 'clk_csr' for legacy case Signed-off-by:
Jianguo Zhang <jianguo.zhang@mediatek.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
-
Jianguo Zhang authored
Update the name of property 'clk_csr' as 'snps,clk-csr' to align with the property name in the binding file. Signed-off-by:
-
Jianguo Zhang authored
Add description for new property snps,clk-csr in binding file Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
Jianguo Zhang authored
Add binding document for the ethernet on mt8188 Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a devlink_health_report message. Fix it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a literal string in the array bnad_net_stats_strings. Fix it. Signed-off-by:
-
Nick Child authored
Implement channel management functions to allow dynamic addition and removal of transmit queues. The `ethtool --show-channels` and `ethtool --set-channels` commands can be used to get and set the number of queues, respectively. Allow the ability to add as many transmit queues as available processors but never allow more than the hard maximum of 16. The number of receive queues is one and cannot be modified. Depending on whether the requested number of queues is larger or smaller than the current value, either allocate or free long term buffers. Since long term buffer construction and destruction can occur in two different areas, from either channel set requests or device open/close, define functions for performing this work. If allocation of a new buffer fails, then attempt to revert back to the previous number of queues. Signed-off-by:
Nick Child <nnac123@linux.ibm.com> Signed-off-by:
-
Nick Child authored
The `ndo_start_xmit` function is protected by a spinlock on the tx queue being used to transmit the skb. Allow concurrent calls to `ndo_start_xmit` by using more than one tx queue. This allows for greater throughput when several jobs are trying to transmit data. Introduce 16 tx queues (leave single rx queue as is) which each correspond to one DMA mapped long term buffer. Signed-off-by:
-
Nick Child authored
Rather than DMA mapping and unmapping every outgoing skb, copy the skb into a buffer that was mapped during the drivers open function. Copying the skb and its frags have proven to be more time efficient than mapping and unmapping. As an effect, performance increases by 3-5 Gbits/s. Allocate and DMA map one continuous 64KB buffer at `ndo_open`. This buffer is maintained until `ibmveth_close` is called. This buffer is large enough to hold the largest possible linnear skb. During `ndo_start_xmit`, copy the skb and all of it's frags into the continuous buffer. By manually linnearizing all the socket buffers, time is saved during memcpy as well as more efficient handling in FW. As a result, we no longer need to worry about the firmware limitation of handling a max of 6 frags. So, we only need to maintain 1 descriptor instead of 6 and can hardcode 0 for the other 5 descriptors during h_send_logical_lan. Since, DMA allocation/mapping issues can no longer arise in xmit functions, we can further reduce code size by removing the need for a bounce buffer on DMA errors. Signed-off-by:
-
Colin Ian King authored
There are spelling mistakes in two literal strings. Fix these. Signed-off-by:
-
Steven Hsieh authored
As 2.5G, 5G ethernet ports are more common and affordable, these ports are being used in LAN bridge devices. STP port_cost() is missing path_cost assignment for these link speeds, causes highest cost 100 being used. This result in lower speed port being picked when there is loop between 5G and 1G ports. Original path_cost: 10G=2, 1G=4, 100m=19, 10m=100 Adjusted path_cost: 10G=2, 5G=3, 2.5G=4, 1G=5, 100m=19, 10m=100 speed greater than 10G = 1 Signed-off-by:Steven Hsieh <steven.hsieh@broadcom.com> Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a netdev_err message. Fix it. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Richard Gobert authored
pskb_may_pull already contains all of the checks performed by pskb_pull. Use pskb_may_pull for validation in pskb_pull, eliminating the duplication and making __pskb_pull obsolete. Replace __pskb_pull with pskb_pull where applicable. Signed-off-by:
Richard Gobert <richardbgobert@gmail.com> Signed-off-by:
-
Wang Yufen authored
Follow the advice of the Documentation/filesystems/sysfs.rst and show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Signed-off-by:
Wang Yufen <wangyufen@huawei.com> Signed-off-by:
-
Wang Yufen authored
Follow the advice of the Documentation/filesystems/sysfs.rst and show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Signed-off-by:
-
Wang Yufen authored
Follow the advice of the Documentation/filesystems/sysfs.rst and show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Signed-off-by:
-
David S. Miller authored
Gerhard Engleder says: ==================== tsnep: multi queue support and some other improvements Add support for additional TX/RX queues along with RX flow classification support. Binding is extended to allow additional interrupts for additional TX/RX queues. Also dma-coherent is allowed as minor improvement. RX path optimisation is done by using page pool as preparations for future XDP support. v4: - rework dma-coherent commit message (Krzysztof Kozlowski) - fixed order of interrupt-names in binding (Krzysztof Kozlowski) - add line break between examples in binding (Krzysztof Kozlowski) - add RX_CLS_LOC_ANY support to RX flow classification v3: - now with changes in cover letter v2: - use netdev_name() (Jakub Kicinski) - use ENOENT if RX flow rule is not found (Jakub Kicinski) - eliminate return code of tsnep_add_rule() (Jakub Kicinski) - remove commit with lazy refill due to depletion problem (Jakub Kicinski) ==================== Signed-off-by: -
Gerhard Engleder authored
Use page pool for RX buffer handling. Makes RX path more efficient and is required prework for future XDP support. Signed-off-by:
Gerhard Engleder <gerhard@engleder-embedded.com> Signed-off-by:
-
Gerhard Engleder authored
Received Ethernet frames are assigned to first RX queue per default. Based on EtherType Ethernet frames can be assigned to other RX queues. This enables processing of real-time Ethernet protocols on dedicated RX queues. Add RX flow classification interface for EtherType based RX queue assignment. Signed-off-by:
-
Gerhard Engleder authored
Support additional TX/RX queue pairs if dedicated interrupt is available. Interrupts are detected by name in device tree. Signed-off-by:
-
Gerhard Engleder authored
For multiple queues multiple interrupts shall be used. Therefore, rework global interrupt to per queue interrupt. Every interrupt name shall contain interface name and queue information. To get a valid interface name, the interrupt request needs to by done during open like in other drivers. Additionally, this allows the removal of some initialisation checks in the interrupt handler. Signed-off-by:
-
Gerhard Engleder authored
Additional TX/RX queue pairs require dedicated interrupts. Extend binding with additional interrupts. Signed-off-by:
-
Gerhard Engleder authored
Within SoCs like ZynqMP, FPGA logic can be connected to different kinds of AXI master ports. Also cache coherent AXI master ports are available. The property "dma-coherent" is used to signal that DMA is cache coherent. Add "dma-coherent" property to allow the configuration of cache coherent DMA. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2022-09-28 (ice) Arkadiusz implements a single pin initialization function, checking feature bits, instead of having separate device functions and updates sub-device IDs for recognizing E810T devices. Martyna adds support for switchdev filters on VLAN priority field. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: ice: Add support for VLAN priority filters in switchdev ice: support features on new E810T variants ice: Merge pin initialization of E810 and E810T adapters ==================== Link: https://lore.kernel.org/r/20220928203217.411078-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Wang Yufen authored
Follow the advice of the Documentation/filesystems/sysfs.rst and show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/1664364860-29153-1-git-send-email-wangyufen@huawei.comSigned-off-by:
-
Jakub Kicinski authored
Vladimir Oltean says: ==================== Add tc-taprio support for queueMaxSDU The tc-taprio offload mode supported by the Felix DSA driver has limitations surrounding its guard bands. The initial discussion was at: https://lore.kernel.org/netdev/c7618025da6723418c56a54fe4683bd7@walle.cc/ with the latest status being that we now have a vsc9959_tas_guard_bands_update() method which makes a best-guess attempt at how much useful space to reserve for packet scheduling in a taprio interval, and how much to reserve for guard bands. IEEE 802.1Q actually does offer a tunable variable (queueMaxSDU) which can determine the max MTU supported per traffic class. In turn we can determine the size we need for the guard bands, depending on the queueMaxSDU. This way we can make the guard band of small taprio intervals smaller than one full MTU worth of transmission time, if we know that said traffic class will transport only smaller packets. As discussed with Gerhard Engleder, the queueMaxSDU may also be useful in limiting the latency on an endpoint, if some of the TX queues are outside of the control of the Linux driver. https://patchwork.kernel.org/project/netdevbpf/patch/20220914153303.1792444-11-vladimir.oltean@nxp.com/ Allow input of queueMaxSDU through netlink into tc-taprio, offload it to the hardware I have access to (LS1028A), and (implicitly) deny non-default values to everyone else. Kurt Kanzenbach has also kindly tested and shared a patch to offload this to hellcreek. v3 at: https://patchwork.kernel.org/project/netdevbpf/cover/20220927234746.1823648-1-vladimir.oltean@nxp.com/ v2 at: https://patchwork.kernel.org/project/netdevbpf/list/?series=679954&state=* v1 at: https://patchwork.kernel.org/project/netdevbpf/cover/20220914153303.1792444-1-vladimir.oltean@nxp.com/ ==================== Link: https://lore.kernel.org/r/20220928095204.2093716-1-vladimir.oltean@nxp.comSigned-off-by:
-
Vladimir Oltean authored
The driver currently sets the PTCMSDUR register statically to the max MTU supported by the interface. Keep this logic if tc-taprio is absent or if the max_sdu for a traffic class is 0, and follow the requested max SDU size otherwise. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
The Port Time Gating Control Register (PTGCR) and Port Time Gating Capability Register (PTGCAPR) have definitions in the driver which aren't in line with the other registers. Rename these. Signed-off-by:
-
Vladimir Oltean authored
The &priv->si->hw construct dereferences 2 pointers and makes lines longer than they need to be, in turn making the code harder to read. Replace &priv->si->hw accesses with a "hw" variable when there are 2 or more accesses within a function that dereference this. This includes loops, since &priv->si->hw is a loop invariant. Signed-off-by:
-
Kurt Kanzenbach authored
Add support for configuring the max SDU per priority and per port. If not specified, keep the default. Signed-off-by:
Kurt Kanzenbach <kurt@linutronix.de> Signed-off-by:
-
Vladimir Oltean authored
The following patch will need to make this function also respond to TC_QUERY_BASE, so make the processing more structured around the tc_setup_type. Signed-off-by:
-
Vladimir Oltean authored
Our current vsc9959_tas_guard_bands_update() algorithm has a limitation imposed by the hardware design. To avoid packet overruns between one gate interval and the next (which would add jitter for scheduled traffic in the next gate), we configure the switch to use guard bands. These are as large as the largest packet which is possible to be transmitted. The problem is that at tc-taprio intervals of sizes comparable to a guard band, there isn't an obvious place in which to split the interval between the useful portion (for scheduling) and the guard band portion (where scheduling is blocked). For example, a 10 us interval at 1Gbps allows 1225 octets to be transmitted. We currently split the interval between the bare minimum of 33 ns useful time (required to schedule a single packet) and the rest as guard band. But 33 ns of useful scheduling time will only allow a single packet to be sent, be that packet 1200 octets in size, or 60 octets in size. It is impossible to send 2 60 octets frames in the 10 us window. Except that if we reduced the guard band (and therefore the maximum allowable SDU size) to 5 us, the useful time for scheduling is now also 5 us, so more packets could be scheduled. The hardware inflexibility of not scheduling according to individual packet lengths must unfortunately propagate to the user, who needs to tune the queueMaxSDU values if he wants to fit more small packets into a 10 us interval, rather than one large packet. Signed-off-by:
-
Vladimir Oltean authored
IEEE 802.1Q clause 12.29.1.1 "The queueMaxSDUTable structure and data types" and 8.6.8.4 "Enhancements for scheduled traffic" talk about the existence of a per traffic class limitation of maximum frame sizes, with a fallback on the port-based MTU. As far as I am able to understand, the 802.1Q Service Data Unit (SDU) represents the MAC Service Data Unit (MSDU, i.e. L2 payload), excluding any number of prepended VLAN headers which may be otherwise present in the MSDU. Therefore, the queueMaxSDU is directly comparable to the device MTU (1500 means L2 payload sizes are accepted, or frame sizes of 1518 octets, or 1522 plus one VLAN header). Drivers which offload this are directly responsible of translating into other units of measurement. To keep the fast path checks optimized, we keep 2 arrays in the qdisc, one for max_sdu translated into frame length (so that it's comparable to skb->len), and another for offloading and for dumping back to the user. Signed-off-by:
-
