- 18 May, 2021 18 commits
-
-
Peng Li authored
Fix the checkpatch error: "foo* bar" should be "foo *bar". Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Peng Li authored
Space prohibited before that close parenthesis ')', so removes the redundant space. Signed-off-by:
-
Peng Li authored
Braces {} are not necessary for single statement blocks, this patch removes redundant braces {}. Signed-off-by: -
Peng Li authored
Add space required before the open parenthesis '(', and add spaces required around that '<', '>' and '!='. Signed-off-by: -
Peng Li authored
This patch removes some redundant blank lines. Signed-off-by:
-
Wei Yongjun authored
Add the missing unlock before return from function qca8k_vlan_add() and qca8k_vlan_del() in the error handling case. Fixes: 028f5f8e ("net: dsa: qca8k: handle error with qca8k_read operation") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Zheng Yejian authored
Since cipso_v4_cache_invalidate() has no return value, so drop related descriptions in its comments. Fixes: 446fda4f ("[NetLabel]: CIPSOv4 engine") Signed-off-by:
Zheng Yejian <zhengyejian1@huawei.com> Acked-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== Add support for custom multipath hash This patchset adds support for custom multipath hash policy for both IPv4 and IPv6 traffic. The new policy allows user space to control the outer and inner packet fields used for the hash computation. Motivation ========== Linux currently supports different multipath hash policies for IPv4 and IPv6 traffic: * Layer 3 * Layer 4 * Layer 3 or inner layer 3, if present These policies hash on a fixed set of fields, which is inflexible and against operators' requirements to control the hash input: "The ability to control the inputs to the hash function should be a consideration in any load-balancing RFP" [1]. An example of this inflexibility can be seen by the fact that none of the current policies allows operators to use the standard 5-tuple and the flow label for multipath hash computation. Such a policy is useful in the following real-world example of a data center with the following types of traffic: * Anycast IPv6 TCP traffic towards layer 4 load balancers. Flow label is constant (zero) to avoid breaking established connections * Non-encapsulated IPv6 traffic. Flow label is used to re-route flows around problematic (congested / failed) paths [2] * IPv6 encapsulated traffic (IPv4-in-IPv6 or IPv6-in-IPv6). Outer flow label is generated from encapsulated packet * UDP encapsulated traffic. Outer source port is generated from encapsulated packet In the above example, using the inner flow information for hash computation in addition to the outer flow information is useful during failures of the BPF agent that selectively generates the flow label based on the traffic type. In such cases, the self-healing properties of the flow label are lost, but encapsulated flows are still load balanced. Control over the inner fields is even more critical when encapsulation is performed by hardware routers. For example, the Spectrum ASIC can only encode 8 bits of entropy in the outer flow label / outer UDP source port when performing IP / UDP encapsulation. In the case of IPv4 GRE encapsulation there is no outer field to encode the inner hash in. User interface ============== In accordance with existing multipath hash configuration, the new custom policy is added as a new option (3) to the net.ipv{4,6}.fib_multipath_hash_policy sysctls. When the new policy is used, the packet fields used for hash computation are determined by the net.ipv{4,6}.fib_multipath_hash_fields sysctls. These sysctls accept a bitmask according to the following table (from ip-sysctl.rst): ====== ============================ 0x0001 Source IP address 0x0002 Destination IP address 0x0004 IP protocol 0x0008 Flow Label 0x0010 Source port 0x0020 Destination port 0x0040 Inner source IP address 0x0080 Inner destination IP address 0x0100 Inner IP protocol 0x0200 Inner Flow Label 0x0400 Inner source port 0x0800 Inner destination port ====== ============================ For example, to allow IPv6 traffic to be hashed based on standard 5-tuple and flow label: # sysctl -wq net.ipv6.fib_multipath_hash_fields=0x0037 # sysctl -wq net.ipv6.fib_multipath_hash_policy=3 Implementation ============== As with existing policies, the new policy relies on the flow dissector to extract the packet fields for the hash computation. However, unlike existing policies that either use the outer or inner flow, the new policy might require both flows to be dissected. To avoid unnecessary invocations of the flow dissector, the data path skips dissection of the outer or inner flows if none of the outer or inner fields are required. In addition, inner flow dissection is not performed when no encapsulation was encountered (i.e., 'FLOW_DIS_ENCAPSULATION' not set by flow dissector) during dissection of the outer flow. Testing ======= Three new selftests are added with three different topologies that allow testing of following traffic combinations: * Non-encapsulated IPv4 / IPv6 traffic * IPv4 / IPv6 overlay over IPv4 underlay * IPv4 / IPv6 overlay over IPv6 underlay All three tests follow the same pattern. Each time a different packet field is used for hash computation. When the field changes in the packet stream, traffic is expected to be balanced across the two paths. When the field does not change, traffic is expected to be unbalanced across the two paths. Patchset overview ================= Patches #1-#3 add custom multipath hash support for IPv4 traffic Patches #4-#7 do the same for IPv6 Patches #8-#10 add selftests Future work =========== mlxsw support can be found here [3]. Changes since RFC v2 [4]: * Patch #2: Document that 0x0008 is used for Flow Label * Patch #2: Do not allow the bitmask to be zero * Patch #6: Do not allow the bitmask to be zero Changes since RFC v1 [5]: * Use a bitmask instead of a bitmap [1] https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3acf3ec3f4b0fd4263989f2e4227bbd1c42b5fe1 [3] https://github.com/idosch/linux/tree/submit/custom_hash_mlxsw_v2 [4] https://lore.kernel.org/netdev/20210509151615.200608-1-idosch@idosch.org/ [5] https://lore.kernel.org/netdev/20210502162257.3472453-1-idosch@idosch.org/ ==================== Signed-off-by: -
Ido Schimmel authored
Test that when the hash policy is set to custom, traffic is distributed only according to the inner fields set in the fib_multipath_hash_fields sysctl. Each time set a different field and make sure traffic is only distributed when the field is changed in the packet stream. The test only verifies the behavior of IPv4/IPv6 overlays on top of an IPv6 underlay network. The previous patch verified the same with an IPv4 underlay network. Example output: # ./ip6gre_custom_multipath_hash.sh TEST: ping [ OK ] TEST: ping6 [ OK ] INFO: Running IPv4 overlay custom multipath hash tests TEST: Multipath hash field: Inner source IP (balanced) [ OK ] INFO: Packets sent on path1 / path2: 6602 / 6002 TEST: Multipath hash field: Inner source IP (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 1 / 12601 TEST: Multipath hash field: Inner destination IP (balanced) [ OK ] INFO: Packets sent on path1 / path2: 6802 / 5801 TEST: Multipath hash field: Inner destination IP (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 12602 / 3 TEST: Multipath hash field: Inner source port (balanced) [ OK ] INFO: Packets sent on path1 / path2: 16431 / 16344 TEST: Multipath hash field: Inner source port (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 0 / 32773 TEST: Multipath hash field: Inner destination port (balanced) [ OK ] INFO: Packets sent on path1 / path2: 16431 / 16344 TEST: Multipath hash field: Inner destination port (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 2 / 32772 INFO: Running IPv6 overlay custom multipath hash tests TEST: Multipath hash field: Inner source IP (balanced) [ OK ] INFO: Packets sent on path1 / path2: 6704 / 5902 TEST: Multipath hash field: Inner source IP (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 1 / 12600 TEST: Multipath hash field: Inner destination IP (balanced) [ OK ] INFO: Packets sent on path1 / path2: 5751 / 6852 TEST: Multipath hash field: Inner destination IP (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 12602 / 0 TEST: Multipath hash field: Inner flowlabel (balanced) [ OK ] INFO: Packets sent on path1 / path2: 8272 / 8181 TEST: Multipath hash field: Inner flowlabel (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 3 / 12602 TEST: Multipath hash field: Inner source port (balanced) [ OK ] INFO: Packets sent on path1 / path2: 16424 / 16351 TEST: Multipath hash field: Inner source port (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 3 / 32774 TEST: Multipath hash field: Inner destination port (balanced) [ OK ] INFO: Packets sent on path1 / path2: 16425 / 16350 TEST: Multipath hash field: Inner destination port (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 2 / 32773 Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Acked-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
-
Ido Schimmel authored
Test that when the hash policy is set to custom, traffic is distributed only according to the inner fields set in the fib_multipath_hash_fields sysctl. Each time set a different field and make sure traffic is only distributed when the field is changed in the packet stream. The test only verifies the behavior of IPv4/IPv6 overlays on top of an IPv4 underlay network. A subsequent patch will do the same with an IPv6 underlay network. Example output: # ./gre_custom_multipath_hash.sh TEST: ping [ OK ] TEST: ping6 [ OK ] INFO: Running IPv4 overlay custom multipath hash tests TEST: Multipath hash field: Inner source IP (balanced) [ OK ] INFO: Packets sent on path1 / path2: 6601 / 6001 TEST: Multipath hash field: Inner source IP (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 0 / 12600 TEST: Multipath hash field: Inner destination IP (balanced) [ OK ] INFO: Packets sent on path1 / path2: 6802 / 5802 TEST: Multipath hash field: Inner destination IP (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 12601 / 1 TEST: Multipath hash field: Inner source port (balanced) [ OK ] INFO: Packets sent on path1 / path2: 16430 / 16344 TEST: Multipath hash field: Inner source port (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 0 / 32772 TEST: Multipath hash field: Inner destination port (balanced) [ OK ] INFO: Packets sent on path1 / path2: 16430 / 16343 TEST: Multipath hash field: Inner destination port (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 0 / 32772 INFO: Running IPv6 overlay custom multipath hash tests TEST: Multipath hash field: Inner source IP (balanced) [ OK ] INFO: Packets sent on path1 / path2: 6702 / 5900 TEST: Multipath hash field: Inner source IP (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 0 / 12601 TEST: Multipath hash field: Inner destination IP (balanced) [ OK ] INFO: Packets sent on path1 / path2: 5751 / 6851 TEST: Multipath hash field: Inner destination IP (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 12602 / 1 TEST: Multipath hash field: Inner flowlabel (balanced) [ OK ] INFO: Packets sent on path1 / path2: 8364 / 8065 TEST: Multipath hash field: Inner flowlabel (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 12601 / 0 TEST: Multipath hash field: Inner source port (balanced) [ OK ] INFO: Packets sent on path1 / path2: 16425 / 16349 TEST: Multipath hash field: Inner source port (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 1 / 32770 TEST: Multipath hash field: Inner destination port (balanced) [ OK ] INFO: Packets sent on path1 / path2: 16425 / 16349 TEST: Multipath hash field: Inner destination port (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 2 / 32770 Signed-off-by:
-
Ido Schimmel authored
Test that when the hash policy is set to custom, traffic is distributed only according to the outer fields set in the fib_multipath_hash_fields sysctl. Each time set a different field and make sure traffic is only distributed when the field is changed in the packet stream. The test only verifies the behavior with non-encapsulated IPv4 and IPv6 packets. Subsequent patches will add tests for IPv4/IPv6 overlays on top of IPv4/IPv6 underlay networks. Example output: # ./custom_multipath_hash.sh TEST: ping [ OK ] TEST: ping6 [ OK ] INFO: Running IPv4 custom multipath hash tests TEST: Multipath hash field: Source IP (balanced) [ OK ] INFO: Packets sent on path1 / path2: 6353 / 6254 TEST: Multipath hash field: Source IP (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 0 / 12600 TEST: Multipath hash field: Destination IP (balanced) [ OK ] INFO: Packets sent on path1 / path2: 6102 / 6502 TEST: Multipath hash field: Destination IP (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 1 / 12601 TEST: Multipath hash field: Source port (balanced) [ OK ] INFO: Packets sent on path1 / path2: 16428 / 16345 TEST: Multipath hash field: Source port (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 32770 / 2 TEST: Multipath hash field: Destination port (balanced) [ OK ] INFO: Packets sent on path1 / path2: 16428 / 16345 TEST: Multipath hash field: Destination port (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 32770 / 2 INFO: Running IPv6 custom multipath hash tests TEST: Multipath hash field: Source IP (balanced) [ OK ] INFO: Packets sent on path1 / path2: 6704 / 5903 TEST: Multipath hash field: Source IP (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 12600 / 0 TEST: Multipath hash field: Destination IP (balanced) [ OK ] INFO: Packets sent on path1 / path2: 5551 / 7052 TEST: Multipath hash field: Destination IP (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 12603 / 0 TEST: Multipath hash field: Flowlabel (balanced) [ OK ] INFO: Packets sent on path1 / path2: 8378 / 8080 TEST: Multipath hash field: Flowlabel (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 2 / 12603 TEST: Multipath hash field: Source port (balanced) [ OK ] INFO: Packets sent on path1 / path2: 16385 / 16388 TEST: Multipath hash field: Source port (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 0 / 32774 TEST: Multipath hash field: Destination port (balanced) [ OK ] INFO: Packets sent on path1 / path2: 16386 / 16390 TEST: Multipath hash field: Destination port (unbalanced) [ OK ] INFO: Packets sent on path1 / path2: 32771 / 2 Signed-off-by:
-
Ido Schimmel authored
Add a new multipath hash policy where the packet fields used for hash calculation are determined by user space via the fib_multipath_hash_fields sysctl that was introduced in the previous patch. The current set of available packet fields includes both outer and inner fields, which requires two invocations of the flow dissector. Avoid unnecessary dissection of the outer or inner flows by skipping dissection if none of the outer or inner fields are required. In accordance with the existing policies, when an skb is not available, packet fields are extracted from the provided flow key. In which case, only outer fields are considered. Signed-off-by:
-
Ido Schimmel authored
A subsequent patch will add a new multipath hash policy where the packet fields used for multipath hash calculation are determined by user space. This patch adds a sysctl that allows user space to set these fields. The packet fields are represented using a bitmask and are common between IPv4 and IPv6 to allow user space to use the same numbering across both protocols. For example, to hash based on standard 5-tuple: # sysctl -w net.ipv6.fib_multipath_hash_fields=0x0037 net.ipv6.fib_multipath_hash_fields = 0x0037 To avoid introducing holes in 'struct netns_sysctl_ipv6', move the 'bindv6only' field after the multipath hash fields. The kernel rejects unknown fields, for example: # sysctl -w net.ipv6.fib_multipath_hash_fields=0x1000 sysctl: setting key "net.ipv6.fib_multipath_hash_fields": Invalid argument Signed-off-by:
-
Ido Schimmel authored
A subsequent patch will add another multipath hash policy where the multipath hash is calculated directly by the policy specific code and not outside of the switch statement. Prepare for this change by moving the multipath hash calculation inside the switch statement. No functional changes intended. Signed-off-by:
-
Ido Schimmel authored
The 'out_timer' label was added in commit 63152fc0 ("[NETNS][IPV6] ip6_fib - gc timer per namespace") when the timer was allocated on the heap. Commit 417f28bb ("netns: dont alloc ipv6 fib timer list") removed the allocation, but kept the label name. Rename it to a more suitable name. Signed-off-by:
-
Ido Schimmel authored
Add a new multipath hash policy where the packet fields used for hash calculation are determined by user space via the fib_multipath_hash_fields sysctl that was introduced in the previous patch. The current set of available packet fields includes both outer and inner fields, which requires two invocations of the flow dissector. Avoid unnecessary dissection of the outer or inner flows by skipping dissection if none of the outer or inner fields are required. In accordance with the existing policies, when an skb is not available, packet fields are extracted from the provided flow key. In which case, only outer fields are considered. Signed-off-by:
-
Ido Schimmel authored
A subsequent patch will add a new multipath hash policy where the packet fields used for multipath hash calculation are determined by user space. This patch adds a sysctl that allows user space to set these fields. The packet fields are represented using a bitmask and are common between IPv4 and IPv6 to allow user space to use the same numbering across both protocols. For example, to hash based on standard 5-tuple: # sysctl -w net.ipv4.fib_multipath_hash_fields=0x0037 net.ipv4.fib_multipath_hash_fields = 0x0037 The kernel rejects unknown fields, for example: # sysctl -w net.ipv4.fib_multipath_hash_fields=0x1000 sysctl: setting key "net.ipv4.fib_multipath_hash_fields": Invalid argument More fields can be added in the future, if needed. Signed-off-by:
-
Ido Schimmel authored
A subsequent patch will add another multipath hash policy where the multipath hash is calculated directly by the policy specific code and not outside of the switch statement. Prepare for this change by moving the multipath hash calculation inside the switch statement. No functional changes intended. Signed-off-by:
-
- 17 May, 2021 22 commits
-
-
Juerg Haefliger authored
Remove leading spaces before tabs in Kconfig file(s) by running the following command: $ find drivers/net -name 'Kconfig*' | xargs sed -r -i 's/^[ ]+\t/\t/' Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Signed-off-by:
-
Jiapeng Chong authored
Variable ret is set to '0' or '-EBUSY', but this value is never read as it is not used later on, hence it is a redundant assignment and can be removed. Clean up the following clang-analyzer warning: net/packet/af_packet.c:3936:4: warning: Value stored to 'ret' is never read [clang-analyzer-deadcode.DeadStores]. net/packet/af_packet.c:3933:4: warning: Value stored to 'ret' is never read [clang-analyzer-deadcode.DeadStores]. No functional change. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
David S. Miller authored
Michael Sit Wei Hong says: ==================== Introducing support for DWC xpcs Energy Efficient Ethernet The goal of this patch set is to enable EEE in the xpcs so that when EEE is enabled, the MAC-->xpcs-->PHY have all the EEE related configurations enabled. Patch 1 adds the functions to enable EEE in the xpcs and sets it to transparent mode. Patch 2 adds the callbacks to configure the xpcs EEE mode. The results are tested by checking the lpi counters of the tx and rx path of the interface. When EEE is enabled, the lpi counters should increament as it enters and exits lpi states. host@EHL$ ethtool --show-eee enp0s30f4 EEE Settings for enp0s30f4: EEE status: disabled Tx LPI: disabled Supported EEE link modes: 100baseT/Full 1000baseT/Full Advertised EEE link modes: Not reported Link partner advertised EEE link modes: 100baseT/Full 1000baseT/Full host@EHL$ ethtool -S enp0s30f4 | grep lpi irq_tx_path_in_lpi_mode_n: 0 irq_tx_path_exit_lpi_mode_n: 0 irq_rx_path_in_lpi_mode_n: 0 irq_rx_path_exit_lpi_mode_n: 0 host@EHL$ ethtool --set-eee enp0s30f4 eee on host@EHL$ [ 110.265154] intel-eth-pci 0000:00:1e.4 enp0s30f4: Link is Down [ 112.315155] intel-eth-pci 0000:00:1e.4 enp0s30f4: Link is Up - 1Gbps/Full - flow control off [ 112.324612] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s30f4: link becomes ready host@EHL$ ethtool --show-eee enp0s30f4 EEE Settings for enp0s30f4: EEE status: enabled - active Tx LPI: 1000000 (us) Supported EEE link modes: 100baseT/Full 1000baseT/Full Advertised EEE link modes: 100baseT/Full 1000baseT/Full Link partner advertised EEE link modes: 100baseT/Full 1000baseT/Full host@EHL$ ethtool -S enp0s30f4 | grep lpi irq_tx_path_in_lpi_mode_n: 6 irq_tx_path_exit_lpi_mode_n: 5 irq_rx_path_in_lpi_mode_n: 7 irq_rx_path_exit_lpi_mode_n: 6 host@EHL$ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.02 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.510 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.489 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.484 ms 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.504 ms 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.466 ms 64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.529 ms 64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.519 ms 64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.518 ms 64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=0.501 ms --- 192.168.1.1 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9216ms rtt min/avg/max/mdev = 0.466/0.553/1.018/0.155 ms host@EHL$ ethtool -S enp0s30f4 | grep lpi irq_tx_path_in_lpi_mode_n: 22 irq_tx_path_exit_lpi_mode_n: 21 irq_rx_path_in_lpi_mode_n: 21 irq_rx_path_exit_lpi_mode_n: 20 ==================== Signed-off-by: -
Michael Sit Wei Hong authored
Link xpcs callback functions for MAC to configure the xpcs EEE feature. The clk_eee frequency is used to calculate the MULT_FACT_100NS. This is to adjust the clock tic closer to 100ns. Signed-off-by:
Michael Sit Wei Hong <michael.wei.hong.sit@intel.com> Signed-off-by:
-
Michael Sit Wei Hong authored
Add DWC xpcs EEE support callbacks.The callback function is used to set EEE registers on xpcs. xpcs transparent mode is enabled to allow PHY to detect MAC EEE status. Signed-off-by:
-
Dan Carpenter authored
We're not holding the lock at this point so "goto unlock;" should be "goto unmap;" Fixes: 4a5fe57e ("alx: use fine-grained locking instead of RTNL") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Loic Poulain authored
The port type is by default part of the WWAN port device name. However device name can not be considered as a 'stable' API and may be subject to change in the future. This change adds a proper device attribute that can be used to determine the WWAN protocol/ type. Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
-
David S. Miller authored
Ezequiel Garcia says: ==================== stmmmac: RK3568 Here's the third version of this patchset, taking the feedback from Heiko and Chen-Yu Tsai. Although this solution is a tad ugly as it hardcodes the register addresses, we believe it's the most robust approach. See: https://lore.kernel.org/netdev/CAGb2v67ZBR=XDFPeXQc429HNu_dbY__-KN50tvBW44fXMs78_w@mail.gmail.com/ This is tested on RK3566 EVB2 and seems to work well. Once the RK3568 devicetree lands upstream, we'll post patches to add network support for RK3566 and RK3568. ==================== Signed-off-by:
-
David Wu authored
Add constants and callback functions for the dwmac present on RK3566/RK3568 SoCs. RK3568 has two MACs, and RK3566 just one, but it's otherwise the same IP core. Signed-off-by:
David Wu <david.wu@rock-chips.com> [Ezequiel: Separate rk3566-gmac support] Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
-
Ezequiel Garcia authored
Add compatible string for RK3568 gmac, and constrain it to be compatible with Synopsys dwmac 4.20a. Signed-off-by:
-
David Wu authored
Add a check for non-null struct rk_gmac_ops for the configured PHY interface mode, failing if unsupported. Signed-off-by:
-
Ezequiel Garcia authored
Some Rockchip platforms have a GMAC4 core, and therefore 'plat_stmmacenet_data.has_gmac' shouldn't be set if 'plat_stmmacenet_data.has_gmac4' is set. Signed-off-by:
-
Yejune Deng authored
Every protocol has the 'netns_ok' member and it is euqal to 1. The 'if (!prot->netns_ok)' always false in inet_add_protocol(). Signed-off-by:
Yejune Deng <yejunedeng@gmail.com> Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Various updates This patchset contains various updates to the mlxsw driver and related selftests. Patches #1-#5 contain various updates to mlxsw selftests. The most significant change is the conversion of the DCB selftests to use the new iproute2 DCB support. Patches #6-#9 contain mostly trivial changes to the driver itself. No user facing changes. Patches #10-#11 remove support for SwitchX-2 and SwitchIB ASICs that did not see any updates in the last 4-5 years and will not see any in the future. See individual commit messages for detailed explanation as to why it is OK to remove these drivers from the kernel. ==================== Signed-off-by: -
Amit Cohen authored
Initial support for the Mellanox SwitchX-2 ASIC was added in July 2015. Since then all development efforts shifted towards the Mellanox Spectrum ASICs and development of this driver stopped beside trivial fixes and refactoring. Therefore, the driver does not support any switch offloads and simply traps all traffic to the CPU, rendering it irrelevant for deployment. In addition, support for this ASIC was dropped by Mellanox a few years ago. Given the driver is not used by any users and that there is no intention of investing in its development, remove it from the kernel. Signed-off-by:
Amit Cohen <amcohen@nvidia.com> Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
-
Amit Cohen authored
Initial support for the Mellanox SwitchIB and SwitchIB-2 ASICs was added in October 2016, but since then development of this driver stopped. Therefore, the driver does not support any offloads and simply registers devlink ports for its front panel ports, rendering it irrelevant for deployment. Given the driver is not used by any users and that there is no intention of investing in its development, remove it from the kernel. Signed-off-by:
-
Ido Schimmel authored
Explicitly set the error code to zero before the goto statement to avoid the following smatch warning: drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3598 mlxsw_sp_nexthop_group_refresh() warn: missing error code 'err' The warning is a false positive, but the change both suppresses the warning and makes it clear to future readers that this is not an error path. The original report and discussion can be found here [1]. [1] https://lore.kernel.org/lkml/202105141823.Td2h3Mbi-lkp@intel.com/ Cc: Dan Carpenter <dan.carpenter@oracle.com> Suggested-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
-
Ido Schimmel authored
mlxsw_emad_transmit() takes care of sending EMAD transactions to the device. Since these transactions can time out, the driver performs up to 5 retransmissions, each time copying the skb with the original request. The data of the skb does not change throughout the process, so there is no need to copy it each time. Instead, only the skb itself can be copied. Therefore, use skb_clone() instead of skb_copy(). This reduces the latency of the function by about 16%. Signed-off-by:
-
Danielle Ratson authored
There are few cases in which an array index queried from a fw register, is accessed without any validation that it doesn't exceed the array length. Add a proper length validation, so accessing memory past the end of an array will be forbidden. Signed-off-by:
Danielle Ratson <danieller@nvidia.com> Signed-off-by:
-
Danielle Ratson authored
In the call path: mlxsw_sp_hdroom_bufs_reset_sizes() mlxsw_sp_hdroom_int_buf_size_get() ->int_buf_size_get() The 'speed' and 'mtu' arguments were mistakenly switched twice. The two bugs thus canceled each other. Clean this up by switching the arguments in both call sites, so that they are passed in the right order. Found during manual code inspection. Signed-off-by: -
Petr Machata authored
Now that the two users of this helper have been converted to iproute2 dcb, it is not necessary anymore. Drop it. Signed-off-by:
-
Petr Machata authored
There is a dedicated tool for configuration of DCB in iproute2 now. Use it in the selftest instead of mlnx_qos. Signed-off-by:
-
