- 13 Mar, 2021 40 commits
-
-
David S. Miller authored
Kurt Kanzenbach says: ==================== net: dsa: hellcreek: Add support for dumping tables add support for dumping the VLAN and FDB table via devlink. As the driver uses internal VLANs and static FDB entries, this is a useful debugging feature. Changes since v1: * Drop memory reporting as there are better APIs to expose this * Move comment to VLAN patch Previous versions: * https://lkml.kernel.org/netdev/20210311175344.3084-1-kurt@kmk-computers.de/ ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Kurt Kanzenbach authored
Allow to dump the FDB table via devlink. This is a useful debugging feature. Signed-off-by:
Kurt Kanzenbach <kurt@kmk-computers.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Kurt Kanzenbach authored
There are two functions which need to populate fdb entries. Move that to a helper function. Signed-off-by:
-
Kurt Kanzenbach authored
hellcreek_select_vlan() takes a boolean instead of an integer. So, use false accordingly. Signed-off-by:
-
Kurt Kanzenbach authored
Allow to dump the VLAN table via devlink. This especially useful, because the driver internally leverages VLANs for the port separation. These are not visible via the bridge utility. Signed-off-by:
-
git://git.open-mesh.org/linux-mergeDavid S. Miller authored
Simon Wunderlich says: ==================== There is only a single patch this time: - Use netif_rx_any_context(), by Sebastian Andrzej Siewior ==================== Signed-off-by: -
David S. Miller authored
Simon Horman says: ==================== net/sched: act_police: add support for packet-per-second policing This series enhances the TC policer action implementation to allow a policer action instance to enforce a rate-limit based on packets-per-second, configurable using a packet-per-second rate and burst parameters. In the hope of aiding review this is broken up into three patches. * [PATCH 1/3] flow_offload: add support for packet-per-second policing Add support for this feature to the flow_offload API that is used to allow programming flows, including TC rules and their actions, into hardware. * [PATCH 2/3] flow_offload: reject configuration of packet-per-second policing in offload drivers Teach all exiting users of the flow_offload API that allow offload of policer action instances to reject offload if packet-per-second rate limiting is configured: none support it at this time * [PATCH 3/3] net/sched: act_police: add support for packet-per-second policing With the above ground-work in place add the new feature to the TC policer action itself With the above in place the feature may be used. As follow-ups we plan to provide: * Corresponding updates to iproute2 * Corresponding self tests (which depend on the iproute2 changes) * Hardware offload support for the NFP driver Key changes since v2: * Added patches 1 and 2, which makes adding patch 3 safe for existing hardware offload of the policer action * Re-worked patch 3 so that a TC policer action instance may be configured for packet-per-second or byte-per-second rate limiting, but not both. * Corrected kdoc usage ==================== Signed-off-by: -
Baowen Zheng authored
Allow a policer action to enforce a rate-limit based on packets-per-second, configurable using a packet-per-second rate and burst parameters. e.g. tc filter add dev tap1 parent ffff: u32 match \ u32 0 0 police pkts_rate 3000 pkts_burst 1000 Testing was unable to uncover a performance impact of this change on existing features. Signed-off-by:Baowen Zheng <baowen.zheng@corigine.com> Signed-off-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
Louis Peens <louis.peens@netronome.com> Signed-off-by:
-
Baowen Zheng authored
A follow-up patch will allow users to configures packet-per-second policing in the software datapath. In preparation for this, teach all drivers that support offload of the policer action to reject such configuration as currently none of them support it. Signed-off-by:
-
Xingfeng Hu authored
Allow flow_offload API to configure packet-per-second policing using rate and burst parameters. Dummy implementations of tcf_police_rate_pkt_ps() and tcf_police_burst_pkt() are supplied which return 0, the unconfigured state. This is to facilitate splitting the offload, driver, and TC code portion of this feature into separate patches with the aim of providing a logical flow for review. And the implementation of these helpers will be filled out by a follow-up patch. Signed-off-by:
Xingfeng Hu <xingfeng.hu@corigine.com> Signed-off-by:
-
David S. Miller authored
Huazhong Tan says: ==================== net: hns3: support imp-controlled PHYs This series adds support for imp-controlled PHYs in the HNS3 ethernet driver. ==================== Signed-off-by: -
Guangbin Huang authored
If the imp-controlled PHYs feature is enabled, driver can not call phy driver interface to set loopback anymore and needs to send command to firmware to start phy loopback. Driver reuses the existing firmware command 0x0315 to start phy loopback, just add a setting bit in this command. As this command is not only for serdes loopback anymore, rename this command to "xxx_COMMON_LOOPBACK", and modify function name, macro name and logs related to it. Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Guangbin Huang authored
When the imp-controlled PHYs feature is enabled, driver will not register mdio bus. In order to support ioctl ops for phy tool to read or write phy register in this case, the firmware implement a new command for driver and driver implement ioctl by using this new command. Signed-off-by:
-
Guangbin Huang authored
When the imp-controlled PHYs feature is enabled, phydev is NULL. In this case, the autoneg is always off when user uses ethtool -a command to get pause parameters because hclge_get_pauseparam() uses phydev to check whether device is TP port. To fit this new feature, use media type to check whether device is TP port. And when user set pause parameters, these parameters need to always set to mac, no matter whether autoneg is off. Signed-off-by:
-
Guangbin Huang authored
IMP(Intelligent Management Processor) firmware add a new feature to take control of PHYs for some new devices, PF driver adds support for this feature. Driver queries device's capability to check whether IMP supports this feature, it will tell IMP to enable this feature by firmware compatible command if it is supported. Signed-off-by:
-
David S. Miller authored
Sergey Shtylyov says: ==================== sh_eth: Improve the register/bit definitions in the Ether driver Here are 4 patches against DaveM's 'net-next' repo. Mainly I'm renaming the register *enum* tags/entries to match the SoC manuals,and also moving the RX-TX descriptor *enum*s closer to the corresponding *struct*s... ==================== Signed-off-by: -
Sergey Shtylyov authored
Place the RX/TX descriptor bit *enum*s where they belong -- after the corresponding RX/TX descriptor *struct*s and, while at it, switch to declaring one *enum* entry per line... Signed-off-by:
Sergey Shtylyov <s.shtylyov@omprussia.ru> Signed-off-by:
-
Sergey Shtylyov authored
Finally, rename the rest of the *enum* tags still not (exactly) matching the abbreviated register names from the manuals... Signed-off-by:
-
Sergey Shtylyov authored
In all the SoC manuals (except R-Car gen2) the PHY status register's name is abbreviated to PSR with the only valid bit 0 named LMON. Follow the suit and rename the corresponding *enum* tag/entry. Signed-off-by:
-
Sergey Shtylyov authored
In all the SoC manuals the TRSCER register bits match the corresponding EESR registers's bits, but only on the R-Car gen2 SoC those are named RINT<n> and TINT<n>. Follow the suit and rename the *enum* tag/entries from DESC_I_* to TRSCER_*. Signed-off-by:
-
David S. Miller authored
Mat Martineau says: ==================== mptcp: Include multiple address ids in RM_ADDR Here's a patch series from the MPTCP tree that extends the capabilities of the MPTCP RM_ADDR header. MPTCP peers can exchange information about their IP addresses that are available for additional MPTCP subflows. IP addresses are advertised with an ADD_ADDR header type, and those advertisements are revoked with the RM_ADDR header type. RFC 8684 allows the RM_ADDR header to include more than one address ID, so multiple advertisements can be revoked in a single header. Previous kernel versions have only used RM_ADDR with a single address ID, so multiple removals required multiple packets. Patches 1-4 plumb address id list structures around the MPTCP code, where before only a single address ID was passed. Patches 5-8 make use of the address lists at the path manager layer that tracks available addresses for both peers. Patches 9-11 update the selftests to cover the new use of RM_ADDR with multiple address IDs. ==================== Signed-off-by: -
Geliang Tang authored
This patch added the testcases for removing a list of addresses. Used the netlink to flush the addresses in the testcases. Signed-off-by:
Geliang Tang <geliangtang@gmail.com> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Geliang Tang authored
The removing testcases can only delete the addresses from id 1, this patch added the support for deleting the addresses from any id that user set. Signed-off-by:
-
Geliang Tang authored
Some of the removing testcases used two zeros as arguments for chk_rm_nr like this: chk_rm_nr 0 0. This doesn't mean that no RM_ADDR has been sent. It only means that RM_ADDR had been sent in the opposite direction that chk_rm_nr is checking. This patch added a new argument invert for chk_rm_nr to allow it can check the RM_ADDR from the opposite direction. Signed-off-by:
-
Geliang Tang authored
This patch invoked mptcp_nl_remove_addrs_list to remove a list of addresses when the netlink flushes addresses, instead of using mptcp_nl_remove_subflow_and_signal_addr to remove them one by one. And dropped the unused parameter net in __flush_addrs too. Signed-off-by:
-
Geliang Tang authored
This patch implemented the function to remove a list of addresses and subflows, named mptcp_nl_remove_addrs_list, which had a input parameter rm_list as the removing addresses list. In mptcp_nl_remove_addrs_list, traverse all the existing msk sockets to invoke mptcp_pm_remove_addrs_and_subflows to remove a list of addresses for each msk socket. In mptcp_pm_remove_addrs_and_subflows, traverse all the addresses in the removing addresses list, to find whether this address is in the conn_list or anno_list. If it is, put the address ID into the removing address list or the removing subflow list, and pass the two lists to mptcp_pm_remove_addr and mptcp_pm_remove_subflow. Signed-off-by:
-
Geliang Tang authored
This patch dealt with removing multi subflows in PM: In mptcp_pm_remove_subflow, changed the input parameter local_id as an list of removing address ids, and passed the list to mptcp_pm_nl_rm_subflow_received. In mptcp_pm_nl_rm_subflow_received, iterated each address id from the received ids list. Then shut down and closed each address id's subsocket. In mptcp_nl_remove_subflow_and_signal_addr, put the single address id into an ids list, and passed it to mptcp_pm_remove_subflow. Signed-off-by:
-
Geliang Tang authored
This patch dropped the member rm_id of struct mptcp_pm_data. Use rm_list_rx in mptcp_pm_nl_rm_addr_received instead of using rm_id. In mptcp_pm_nl_rm_addr_received, iterated each address id from pm.rm_list_rx, then shut down and closed each address id's subsocket. Signed-off-by:
-
Geliang Tang authored
This patch added a new member rm_list_rx for struct mptcp_pm_data as an list of the removing address ids on the incoming direction. Initialized its nr field to zero in mptcp_pm_data_init. In mptcp_pm_rm_addr_received, set it as the input rm_list. Signed-off-by:
-
Geliang Tang authored
This patch changed the member rm_id in struct mptcp_options_received as a list of the removing address ids, and renamed it to rm_list. In mptcp_parse_option, parsed the RM_ADDR suboption and filled them into the rm_list in struct mptcp_options_received. In mptcp_incoming_options, passed this rm_list to the function mptcp_pm_rm_addr_received. It also changed the parameter type of mptcp_pm_rm_addr_received. Signed-off-by:
-
Geliang Tang authored
This patch added a new member rm_list_tx for struct mptcp_pm_data as the removing address list on the outgoing direction. Initialize its nr field to zero in mptcp_pm_data_init. In mptcp_pm_remove_anno_addr, put the single address id into an removing list, and passed it to mptcp_pm_remove_addr. In mptcp_pm_remove_addr, save the input rm_list to rm_list_tx in struct mptcp_pm_data. Signed-off-by:
-
Geliang Tang authored
This patch defined a new struct mptcp_rm_list, the ids field was an array of the removing address ids, the nr field was the valid number of removing address ids in the array. The array size was definced as a new macro MPTCP_RM_IDS_MAX. Changed the member rm_id of struct mptcp_out_options to rm_list. In mptcp_established_options_rm_addr, invoked mptcp_pm_rm_addr_signal to get the rm_list. According the number of addresses in it, calculated the padded RM_ADDR suboption length. And saved the ids array in struct mptcp_out_options's rm_list member. In mptcp_write_options, iterated each address id from struct mptcp_out_options's rm_list member, set the invalid ones as TCPOPT_NOP, then filled them into the RM_ADDR suboption. Changed TCPOLEN_MPTCP_RM_ADDR_BASE from 4 to 3. Signed-off-by:
-
David S. Miller authored
Petr Machata says: ==================== net: Resilient NH groups: netdevsim, selftests Support for resilient next-hop groups was added in a previous patch set. Resilient next hop groups add a layer of indirection between the SKB hash and the next hop. Thus the hash is used to reference a hash table bucket, which is then used to reference a particular next hop. This allows the system more flexibility when assigning SKB hash space to next hops. Previously, each next hop had to be assigned a continuous range of SKB hash space. With a hash table as an intermediate layer, it is possible to reassign next hops with a hash table bucket granularity. In turn, this mends issues with traffic flow redirection resulting from next hop removal or adjustments in next-hop weights. This patch set introduces mock offloading of resilient next hop groups by the netdevsim driver, and a suite of selftests. - Patch #1 adds a netdevsim-specific lock to protect next-hop hashtable. Previously, netdevsim relied on RTNL to maintain mutual exclusion. Patch #2 extracts a helper to make the following patches clearer. - Patch #3 implements the support for offloading of resilient next-hop groups. - Patch #4 introduces a new debugfs interface to set activity on a selected next-hop bucket. This simulates how HW can periodically report bucket activity, and buckets thus marked are expected to be exempt from migration to new next hops when the group changes. - Patches #5 and #6 clean up the fib_nexthop selftests. - Patches #7, #8 and #9 add tests for resilient next hop groups. Patch #7 adds resilient-hashing counterparts to fib_nexthops.sh. Patch #8 adds a new traffic test for resilient next-hop groups. Patch #9 adds a new traffic test for tunneling. - Patch #10 actually leverages the netdevsim offload to implement a suite of algorithmic tests that verify how and when buckets are migrated under various simulated workload scenarios. The overall plan is to contribute approximately the following patchsets: 1) Nexthop policy refactoring (already pushed) 2) Preparations for resilient next hop groups (already pushed) 3) Implementation of resilient next hop group (already pushed) 4) Netdevsim offload plus a suite of selftests (this patchset) 5) Preparations for mlxsw offload of resilient next-hop groups 6) mlxsw offload including selftests Interested parties can look at the complete code at [2]. [1] https://tools.ietf.org/html/rfc2992 [2] https://github.com/idosch/linux/commits/submit/res_integ_v1 ==================== Signed-off-by:
-
Ido Schimmel authored
Test various aspects of the resilient nexthop group offload API on top of the netdevsim implementation. Both good and bad flows are tested. Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Co-developed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
-
Ido Schimmel authored
Add a resilient nexthop objects version of gre_multipath_nh.sh. Test that both IPv4 and IPv6 overlays work with resilient nexthop groups where the nexthops are two GRE tunnels. Signed-off-by:
-
Ido Schimmel authored
Verify that IPv4 and IPv6 multipath forwarding works correctly with resilient nexthop groups and with different weights. Test that when the idle timer is not zero, the resilient groups are not rebalanced - because the nexthop buckets are considered active - and the initial weights (1:1) are used. Signed-off-by:
-
Ido Schimmel authored
Add test cases for resilient nexthop groups. Exhaustive forwarding tests are added separately under net/forwarding/. Examples: # ./fib_nexthops.sh -t basic_res Basic resilient nexthop group functional tests ---------------------------------------------- TEST: Add a nexthop group with default parameters [ OK ] TEST: Get a nexthop group with default parameters [ OK ] TEST: Get a nexthop group with non-default parameters [ OK ] TEST: Add a nexthop group with 0 buckets [ OK ] TEST: Replace nexthop group parameters [ OK ] TEST: Get a nexthop group after replacing parameters [ OK ] TEST: Replace idle timer [ OK ] TEST: Get a nexthop group after replacing idle timer [ OK ] TEST: Replace unbalanced timer [ OK ] TEST: Get a nexthop group after replacing unbalanced timer [ OK ] TEST: Replace with no parameters [ OK ] TEST: Get a nexthop group after replacing no parameters [ OK ] TEST: Replace nexthop group type - implicit [ OK ] TEST: Replace nexthop group type - explicit [ OK ] TEST: Replace number of nexthop buckets [ OK ] TEST: Get a nexthop group after replacing with invalid parameters [ OK ] TEST: Dump all nexthop buckets [ OK ] TEST: Dump all nexthop buckets in a group [ OK ] TEST: Dump all nexthop buckets with a specific nexthop device [ OK ] TEST: Dump all nexthop buckets with a specific nexthop identifier [ OK ] TEST: Dump all nexthop buckets in a non-existent group [ OK ] TEST: Dump all nexthop buckets in a non-resilient group [ OK ] TEST: Dump all nexthop buckets using a non-existent device [ OK ] TEST: Dump all nexthop buckets with invalid 'groups' keyword [ OK ] TEST: Dump all nexthop buckets with invalid 'fdb' keyword [ OK ] TEST: Get a valid nexthop bucket [ OK ] TEST: Get a nexthop bucket with valid group, but invalid index [ OK ] TEST: Get a nexthop bucket from a non-resilient group [ OK ] TEST: Get a nexthop bucket from a non-existent group [ OK ] Tests passed: 29 Tests failed: 0 # ./fib_nexthops.sh -t ipv4_large_res_grp IPv4 large resilient group (128k buckets) ----------------------------------------- TEST: Dump large (x131072) nexthop buckets [ OK ] Tests passed: 1 Tests failed: 0 # ./fib_nexthops.sh -t ipv6_large_res_grp IPv6 large resilient group (128k buckets) ----------------------------------------- TEST: Dump large (x131072) nexthop buckets [ OK ] Tests passed: 1 Tests failed: 0 # ./fib_nexthops.sh -t ipv4_res_torture IPv4 runtime resilient nexthop group torture -------------------------------------------- TEST: IPv4 resilient nexthop group torture test [ OK ] Tests passed: 1 Tests failed: 0 # ./fib_nexthops.sh -t ipv6_res_torture IPv6 runtime resilient nexthop group torture -------------------------------------------- TEST: IPv6 resilient nexthop group torture test [ OK ] Tests passed: 1 Tests failed: 0 # ./fib_nexthops.sh -t ipv4_res_grp_fcnal IPv4 resilient groups functional -------------------------------- TEST: Nexthop group updated when entry is deleted [ OK ] TEST: Nexthop buckets updated when entry is deleted [ OK ] TEST: Nexthop group updated after replace [ OK ] TEST: Nexthop buckets updated after replace [ OK ] TEST: Nexthop group updated when entry is deleted - nECMP [ OK ] TEST: Nexthop buckets updated when entry is deleted - nECMP [ OK ] TEST: Nexthop group updated after replace - nECMP [ OK ] TEST: Nexthop buckets updated after replace - nECMP [ OK ] Tests passed: 8 Tests failed: 0 # ./fib_nexthops.sh -t ipv6_res_grp_fcnal IPv6 resilient groups functional -------------------------------- TEST: Nexthop group updated when entry is deleted [ OK ] TEST: Nexthop buckets updated when entry is deleted [ OK ] TEST: Nexthop group updated after replace [ OK ] TEST: Nexthop buckets updated after replace [ OK ] TEST: Nexthop group updated when entry is deleted - nECMP [ OK ] TEST: Nexthop buckets updated when entry is deleted - nECMP [ OK ] TEST: Nexthop group updated after replace - nECMP [ OK ] TEST: Nexthop buckets updated after replace - nECMP [ OK ] Tests passed: 8 Tests failed: 0 Signed-off-by:
-
Ido Schimmel authored
The lines with the IPv4 and IPv6 test cases are already very long and more test cases will be added in subsequent patches. List each test case in a different line to make it easier to extend the test with more test cases. Signed-off-by:
-
Ido Schimmel authored
Before: # ./fib_nexthops.sh -t ipv4_torture IPv4 runtime torture -------------------- TEST: IPv4 torture test [ OK ] ./fib_nexthops.sh: line 213: 19376 Killed ipv4_del_add_loop1 ./fib_nexthops.sh: line 213: 19377 Killed ipv4_grp_replace_loop ./fib_nexthops.sh: line 213: 19378 Killed ip netns exec me ping -f 172.16.101.1 > /dev/null 2>&1 ./fib_nexthops.sh: line 213: 19380 Killed ip netns exec me ping -f 172.16.101.2 > /dev/null 2>&1 ./fib_nexthops.sh: line 213: 19381 Killed ip netns exec me mausezahn veth1 -B 172.16.101.2 -A 172.16.1.1 -c 0 -t tcp "dp=1-1023, flags=syn" > /dev/null 2>&1 Tests passed: 1 Tests failed: 0 # ./fib_nexthops.sh -t ipv6_torture IPv6 runtime torture -------------------- TEST: IPv6 torture test [ OK ] ./fib_nexthops.sh: line 213: 24453 Killed ipv6_del_add_loop1 ./fib_nexthops.sh: line 213: 24454 Killed ipv6_grp_replace_loop ./fib_nexthops.sh: line 213: 24456 Killed ip netns exec me ping -f 2001:db8:101::1 > /dev/null 2>&1 ./fib_nexthops.sh: line 213: 24457 Killed ip netns exec me ping -f 2001:db8:101::2 > /dev/null 2>&1 ./fib_nexthops.sh: line 213: 24458 Killed ip netns exec me mausezahn -6 veth1 -B 2001:db8:101::2 -A 2001:db8:91::1 -c 0 -t tcp "dp=1-1023, flags=syn" > /dev/null 2>&1 Tests passed: 1 Tests failed: 0 After: # ./fib_nexthops.sh -t ipv4_torture IPv4 runtime torture -------------------- TEST: IPv4 torture test [ OK ] Tests passed: 1 Tests failed: 0 # ./fib_nexthops.sh -t ipv6_torture IPv6 runtime torture -------------------- TEST: IPv6 torture test [ OK ] Tests passed: 1 Tests failed: 0 Signed-off-by:
-
Ido Schimmel authored
A key component of the resilient hashing algorithm is the hash buckets' activity. If a bucket is active, it will not be populated with a new nexthop in order not to break existing flows. Therefore, in order to easily and thoroughly test the algorithm, we need to be in full control over the reported activity. Add a debugfs interface that allows user space to have netdevsim report a nexthop bucket within a resilient nexthop group as active. For example: # echo 10 23 > /sys/kernel/debug/netdevsim/netdevsim10/fib/nexthop_bucket_activity Will mark bucket 23 in nexthop group 10 as active. Signed-off-by:
-
