- 27 Feb, 2020 40 commits
-
-
David S. Miller authored
Jiri Pirko says: ==================== selftests: updates for mlxsw driver test This patchset contains tweaks to the existing tests and is also adding couple of new ones, namely tests for shared buffer and red offload. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Amit Cohen authored
The scale test for Spectrum-2 should be invoked for Spectrum-2 and Spectrum-3. Add the appropriate device ID. Signed-off-by:
Amit Cohen <amitc@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Danielle Ratson authored
Currently, the test inserts X /32 routes and for each route it is testing that a packet sent from the first host is received by the second host, which is very time-consuming. Instead only validate the offload flag of each route and get the same result. Wait between the creation of the routes and the offload validation in order to make sure that all the routes were successfully offloaded. Signed-off-by:
Danielle Ratson <danieller@mellanox.com> Signed-off-by:
-
Danielle Ratson authored
After adding a given number of flower rules for different IPv6 addresses, the test generates traffic and ensures that each packet is received, which is time-consuming. Instead, test the offload indication of the tc flower rules and reduce the running time by half. Signed-off-by:
-
Shalom Toledo authored
Test the max shared buffer occupancy for port's pool and port's TC's (using different types of packets). Signed-off-by:
Shalom Toledo <shalomt@mellanox.com> Signed-off-by:
-
Shalom Toledo authored
Add mlxsw lib for common defines, helpers etc. Signed-off-by:
-
Shalom Toledo authored
Add two devlink port helpers: * devlink port get by netdev * devlink cpu port get Signed-off-by:
-
Shalom Toledo authored
Sanity check for devlink info command. Signed-off-by:
-
Shalom Toledo authored
Test physical ports' shared buffer configuration options using random values related to a specific configuration option. There are 3 configuration options: pool, TC bind and portpool. Each sub-test, test a different configuration option and random the related values as the follow: * For pools, pool's size will be randomized. * For TC bind, pool number and threshold will be randomized. * For portpools, threshold will be randomized. Signed-off-by:
-
Danielle Ratson authored
Rtnetlink test uses offload indication checks. Use a busywait helper and wait until the offload indication is set or fail if it reaches timeout. Signed-off-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
-
Danielle Ratson authored
Vxlan test uses offload indication checks. Use a busywait helper and wait until the offload indication is set or fail if it reaches timeout. Signed-off-by:
-
Danielle Ratson authored
Blackhole routes test uses offload indication checks. Use busywait helper and wait until the routes offload indication is set or fail if it reaches timeout. Signed-off-by:
-
Ido Schimmel authored
The test checks that packets are trapped when they should egress a router interface (RIF) that has become disabled. This is a temporary state in a RIF's deletion sequence. Currently, the test deletes the RIF by flushing all the IP addresses configured on the associated netdev (br0). However, this is racy, as this also flushes all the routes pointing to the netdev and if the routes are deleted from the device before the RIF is disabled, then no packets will try to egress the disabled RIF and the trap will not be triggered. Instead, trigger the deletion of the RIF by unlinking the mlxsw port from the bridge that is backing the RIF. Unlike before, this will not cause the kernel to delete the routes pointing to the bridge. Note that due to current mlxsw locking scheme the RIF is always deleted first, but this is going to change. Signed-off-by:
-
Jiri Pirko authored
Include test of forbidding to have multiple mirror actions. Signed-off-by:
-
Jiri Pirko authored
Include test of forbidding to have redirect rule on egress-bound block. Signed-off-by:
-
Petr Machata authored
This tests that below the queue minimum length, there is no dropping / marking, and above max, everything is dropped / marked. The test is structured as a core file with topology and test code, and three wrappers: one for RED used as a root Qdisc, and two for testing (W)RED under PRIO and ETS. Signed-off-by:
-
Petr Machata authored
Extract a helper __start_traffic() configurable by protocol type. Allow passing through extra mausezahn arguments. Add a wrapper, start_tcp_traffic(). Signed-off-by:
-
David S. Miller authored
Russell King says: ==================== VLANs, DSA switches and multiple bridges This is a repost of the previously posted RFC back in December, which did not get fully reviewed. I've dropped the RFC tag this time as no one really found anything too problematical in the RFC posting. I've been trying to configure DSA for VLANs and not having much success. The setup is quite simple: - The main network is untagged - The wifi network is a vlan tagged with id $VN running over the main network. I have an Armada 388 Clearfog with a PCIe wifi card which I'm trying to setup to provide wifi access to the vlan $VN network, while the switch is also part of the main network. However, I'm encountering problems: 1) vlan support in DSA has a different behaviour from the Linux software bridge implementation. # bridge vlan port vlan ids lan1 1 PVID Egress Untagged ... shows the default setup - the bridge ports are all configured for vlan 1, untagged egress, and vlan 1 as the port vid. Issuing: # ip li set dev br0 type bridge vlan_filtering 1 with no other vlan configuration commands on a Linux software bridge continues to allow untagged traffic to flow across the bridge. This difference in behaviour is because the MV88E6xxx VTU is completely empty - because net/dsa ignores all vlan settings for a port if br_vlan_enabled(dp->bridge_dev) is false - this reflects the vlan filtering state of the bridge, not whether the bridge is vlan aware. What this means is that attempting to configure the bridge port vlans before enabling vlan filtering works for Linux software bridges, but fails for DSA bridges. 2) Assuming the above is sorted, we move on to the next issue, which is altogether more weird. Let's take a setup where we have a DSA bridge with lan1..6 in a bridge device, br0, with vlan filtering enabled. lan1 is the upstream port, lan2 is a downstream port that also wants to see traffic on vlan id $VN. Both lan1 and lan2 are configured for that: # bridge vlan add vid $VN dev lan1 # bridge vlan add vid $VN dev lan2 # ip li set br0 type bridge vlan_filtering 1 Untagged traffic can now pass between all the six lan ports, and vlan $VN between lan1 and lan2 only. The MV88E6xxx 8021q_mode debugfs file shows all lan ports are in mode "secure" - this is important! /sys/class/net/br0/bridge/vlan_filtering contains 1. tcpdumping from another machine on lan4 shows that no $VN traffic reaches it. Everything seems to be working correctly... In order to further bridge vlan $VN traffic to hostapd's wifi interface, things get a little more complex - we can't add hostapd's wifi interface to br0 directly, because hostapd will bring up the wifi interface and leak the main, untagged traffic onto the wifi. (hostapd does have vlan support, but only as a dynamic per-client thing, and there's no hooks I can see to allow script-based config of the network setup before hostapd up's the wifi interface.) So, what I tried was: # ip li add link br0 name br0.$VN type vlan id $VN # bridge vlan add vid $VN dev br0 self # ip li set dev br0.$VN up So far so good, we get a vlan interface on top of the bridge, and tcpdumping it shows we get traffic. The 8021q_mode file has not changed state. Everything still seems to be correct. # bridge addbr br1 Still nothing has changed. # bridge addif br1 br0.$VN And now the 8021q_mode debugfs file shows that all ports are now in "disabled" mode, but /sys/class/net/br0/bridge/vlan_filtering still contains '1'. In other words, br0 still thinks vlan filtering is enabled, but the hardware has had vlan filtering disabled. Adding some stack traces to an appropriate point indicates that this is because __switchdev_handle_port_attr_set() recurses down through the tree of interfaces, skipping over the vlan interface, applying br1's configuration to br0's ports. This surely can not be right - surely __switchdev_handle_port_attr_set() and similar should stop recursing down through another master bridge device? There are probably other network device classes that switchdev shouldn't recurse down too. I've considered whether switchdev is the right level to do it, and I think it is - as we want the check/set callbacks to be called for the top level device even if it is a master bridge device, but we don't want to recurse through a lower master bridge device. v2: dropped patch 3, since that has an outstanding issue, and my question on it has not been answered. Otherwise, these are the same patches. Maybe we can move forward with just these two? v3: include DSA ports in patch 2 ==================== Signed-off-by: -
Russell King authored
When setting VLANs on DSA switches, the VLAN is added to both the port concerned as well as the CPU port by dsa_slave_vlan_add(), as well as any DSA ports. If multiple ports are configured with the same VLAN ID, this triggers a warning on the CPU and DSA ports. Avoid this warning for CPU and DSA ports. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Russell King authored
When configuring a tree of independent bridges, propagating changes from the upper bridge across a bridge master to the lower bridge ports brings surprises. For example, a lower bridge may have vlan filtering enabled. It may have a vlan interface attached to the bridge master, which may then be incorporated into another bridge. As soon as the lower bridge vlan interface is attached to the upper bridge, the lower bridge has vlan filtering disabled. This occurs because switchdev recursively applies its changes to all lower devices no matter what. Reviewed-by:
-
Dan Carpenter authored
The callers only expect NULL pointers, so returning an error pointer will lead to an Oops. Fixes: 0c2204a4 ("net: qrtr: Migrate nameservice to kernel from userspace") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Antoine Tenart authored
This patch adds a missing shift for the media operation mode selection. This does not fix the driver as the current operation mode (copper) has a value of 0, but this wouldn't work for other modes. Signed-off-by:
Antoine Tenart <antoine.tenart@bootlin.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Arthur Kiyanovski authored
In this commit we revert the part of commit 1a63443a ("net/amazon: Ensure that driver version is aligned to the linux kernel"), which breaks the interface between the ENA driver and FW. We also replace the use of DRIVER_VERSION with DRIVER_GENERATION when we bring back the deleted constants that are used in interface with ENA device FW. This commit does not change the driver version reported to the user via ethtool, which remains the kernel version. Fixes: 1a63443a ("net/amazon: Ensure that driver version is aligned to the linux kernel") Signed-off-by:
Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by:
-
David S. Miller authored
Florian Westphal says: ==================== mptcp: update mptcp ack sequence outside of recv path This series moves mptcp-level ack sequence update outside of the recvmsg path. Current approach has two problems: 1. There is delay between arrival of new data and the time we can ack this data. 2. If userspace doesn't call recv for some time, mptcp ack_seq is not updated at all, even if this data is queued in the subflow socket receive queue. Move skbs from the subflow socket receive queue to the mptcp-level receive queue, updating the mptcp-level ack sequence and have recv take skbs from the mptcp-level receive queue. The first place where we will attempt to update the mptcp level acks is from the subflows' data_ready callback, even before we make userspace aware of new data. Because of possible deadlock (we need to take the mptcp socket lock while already holding the subflow sockets lock), we may still need to defer the mptcp-level ack update. In such case, this work will be either done from work queue or recv path, depending on which runs sooner. In order to avoid pointless scheduling of the work queue, work will be queued from the mptcp sockets lock release callback. This allows to detect when the socket owner did drain the subflow socket receive queue. Please see individual patches for more information. ==================== Signed-off-by: -
Paolo Abeni authored
Don't schedule the work queue right away, instead defer this to the lock release callback. This has the advantage that it will give recv path a chance to complete -- this might have moved all pending packets from the subflow to the mptcp receive queue, which allows to avoid the schedule_work(). Co-developed-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Reviewed-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Florian Westphal authored
We can't lock_sock() the mptcp socket from the subflow data_ready callback, it would result in ABBA deadlock with the subflow socket lock. We can however grab the spinlock: if that succeeds and the mptcp socket is not owned at the moment, we can process the new skbs right away without deferring this to the work queue. This avoids the schedule_work and hence the small delay until the work item is processed. Signed-off-by:
-
Florian Westphal authored
Only used to discard stale data from the subflow, so move it where needed. Signed-off-by:
-
Florian Westphal authored
If userspace never drains the receive buffers we must stop draining the subflow socket(s) at some point. This adds the needed rmem accouting for this. If the threshold is reached, we stop draining the subflows. Signed-off-by:
-
Florian Westphal authored
If userspace is not reading data, all the mptcp-level acks contain the ack_seq from the last time userspace read data rather than the most recent in-sequence value. This causes pointless retransmissions for data that is already queued. The reason for this is that all the mptcp protocol level processing happens at mptcp_recv time. This adds work queue to move skbs from the subflow sockets receive queue on the mptcp socket receive queue (which was not used so far). This allows us to announce the correct mptcp ack sequence in a timely fashion, even when the application does not call recv() on the mptcp socket for some time. We still wake userspace tasks waiting for POLLIN immediately: If the mptcp level receive queue is empty (because the work queue is still pending) it can be filled from in-sequence subflow sockets at recv time without a need to wait for the worker. The skb_orphan when moving skbs from subflow to mptcp level is needed, because the destructor (sock_rfree) relies on skb->sk (ssk!) lock being taken. A followup patch will add needed rmem accouting for the moved skbs. Other problem: In case application behaves as expected, and calls recv() as soon as mptcp socket becomes readable, the work queue will only waste cpu cycles. This will also be addressed in followup patches. Signed-off-by:
-
Paolo Abeni authored
Will be extended with functionality in followup patches. Initial user is moving skbs from subflows receive queue to the mptcp-level receive queue. Signed-off-by:
-
Florian Westphal authored
allows us to schedule the work queue to drain the ssk receive queue in a followup patch. This is needed to avoid sending all-to-pessimistic mptcp-level acknowledgements. At this time, the ack_seq is what was last read by userspace instead of the highest in-sequence number queued for reading. Signed-off-by:
-
David S. Miller authored
Jiri Pirko says: ==================== mlxsw: Small driver update This patchset contains couple of patches not related to each other. They are small optimization and extension changes to the driver. ==================== Signed-off-by: -
Petr Machata authored
The buffer factor on Spectrum-3 is larger than on Spectrum-2. Add a new callback and use it for mlxsw_sp->span_ops on Spectrum-3. Signed-off-by:
-
Ido Schimmel authored
During port initialization the driver instructs the device to only advertise speeds that can be supported by the port's current width. Since the device now returns the supported speeds based on the port's current width, the driver no longer needs to compute the speeds that can be advertised. Simplify port initialization by setting the advertised speeds to the queried supported speeds. Signed-off-by:
-
Petr Machata authored
Spectrum-1 and Spectrum-2 do not have a per-TC counter of number of packets marked by ECN. The value reported currently is the total number of marked packets. Showing this value at individual TC Qdiscs is misleading. Move the counter to ethtool instead. Signed-off-by:
-
Jiri Pirko authored
Currently, only one SFN query is done from repetitive work at a time, processing 64 entries. Another work iteration is scheduled in 100ms, that means that the max rate of learned FDB entries is limited to 6400/s. That is slow. Fix this by doing 2 optimizations: 1) Run 10 SFN queries at a time. 2) In case the SFN is not drained, schedule work with 0 delay to allow to continue processing rest of the records. On a testing setup with 500K entries the time to process decreased from 870secs to 10secs. Signed-off-by:
Alex Kushnarov <alexanderk@mellanox.com> Signed-off-by:
-
Randy Dunlap authored
When debugging via dprintk() is not enabled, make the dprintk() macro be an empty do-while loop, as is done in <linux/sunrpc/debug.h>. This fixes a gcc warning when -Wextra is set: ../net/llc/af_llc.c:974:51: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] I have verified that there is not object code change (with gcc 7.5.0). Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: netdev@vger.kernel.org Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5-updates-2020-02-25 The following series provides some misc updates to mlx5 driver: 1) From Maxim, Refactoring for mlx5e netdev channels recreation flow. - Add error handling - Add context to the preactivate hook - Use preactivate hook with context where it can be used and subsequently unify channel recreation flow everywhere. - Fix XPS cpumask to not reset upon channel recreation. 2) From Tariq: - Use indirect calls wrapper on RX. - Check LRO capability bit 3) Multiple small cleanups ==================== Signed-off-by: -
David S. Miller authored
Hans Wippel says: ==================== net/smc: improve peer ID in CLC decline The following two patches improve the peer ID in CLC decline messages if RoCE devices are present in the host but no suitable device is found for a connection. The first patch reworks the peer ID initialization. The second patch contains the actual changes of the CLC decline messages. Changes v1 -> v2: * make smc_ib_is_valid_local_systemid() static in first patch * changed if in smc_clc_send_decline() to remove curly braces Changes RFC -> v1: * split the patch into two parts * removed zero assignment to global variable (thanks Leon) Thanks to Leon Romanovsky and Karsten Graul for the feedback! ==================== Signed-off-by: -
Hans Wippel authored
According to RFC 7609, all CLC messages contain a peer ID that consists of a unique instance ID and the MAC address of one of the host's RoCE devices. But if a SMC-R connection cannot be established, e.g., because no matching pnet table entry is found, the current implementation uses a zero value in the CLC decline message although the host's peer ID is set to a proper value. If no RoCE and no ISM device is usable for a connection, there is no LGR and the LGR check in smc_clc_send_decline() prevents that the peer ID is copied into the CLC decline message for both SMC-D and SMC-R. So, this patch modifies the check to also accept the case of no LGR. Also, only a valid peer ID is copied into the decline message. Signed-off-by:
Hans Wippel <ndev@hwipl.net> Signed-off-by:
-
