netdev CI testing #6666
Open
netdev CI testing #6666
+49,654
−17,196
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kernel-patches-daemon-bpf
bot
force-pushed
the
bpf-next_base
branch
3 times, most recently
from
4f22ee0 to
8a9a8e0
Compare
kuba-moo
force-pushed
the
to-test
branch
11 times, most recently
from
64c403f to
8da1f58
Compare
kernel-patches-daemon-bpf
bot
force-pushed
the
bpf-next_base
branch
3 times, most recently
from
78ebb17 to
9325308
Compare
kuba-moo
force-pushed
the
to-test
branch
6 times, most recently
from
c8c7b2f to
a71aae6
Compare
kernel-patches-daemon-bpf
bot
force-pushed
the
bpf-next_base
branch
from
9325308 to
7940ae1
Compare
kuba-moo
force-pushed
the
to-test
branch
2 times, most recently
from
d8feb00 to
b16a6b9
Compare
kernel-patches-daemon-bpf
bot
force-pushed
the
bpf-next_base
branch
from
7940ae1 to
8f1ff3c
Compare
kuba-moo
force-pushed
the
to-test
branch
2 times, most recently
from
4164329 to
c5cecb3
Compare
Extend the devcom framework to support namespace-aware components. The existing devcom matching logic was based solely on numeric keys, limiting its use to the global (init_net) scope or requiring clients to ignore namespaces altogether, both of which are incorrect in multi-namespace environments. This patch introduces namespace support by allowing devcom clients to provide a namespace match attribute. The devcom pairing mechanism is updated to compare the namespace, enabling proper isolation and interaction of components across different net namespaces. With this change, components that require namespace aware pairing, such as SD groups or LAG, can now work correctly in multi-namespace scenarios. In particular, this opens the way to support hardware LAG within a net namespace. Signed-off-by: Shay Drory <[email protected]> Reviewed-by: Mark Bloch <[email protected]> Reviewed-by: Parav Pandit <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Update the LAG implementation to support net namespace isolation. With recent changes to the devcom framework allowing namespace-aware matching, the LAG layer is updated to register devcom clients with the associated net namespace. This ensures that LAG formation only occurs between mlx5 interfaces that reside in the same namespace. This change ensures that devices in different namespaces do not interfere with each other's LAG setup and behavior. For example, if two PCI PFs are in the same namespace, they are eligible to form a hardware LAG. In addition, reload behavior for LAG is adjusted to handle namespace contexts appropriately. Signed-off-by: Shay Drory <[email protected]> Reviewed-by: Mark Bloch <[email protected]> Reviewed-by: Parav Pandit <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Write combining is an optimization feature in CPUs that is frequently used by modern devices to generate 32 or 64 byte TLPs at the PCIe level. These large TLPs allow certain optimizations in the driver to HW communication that improve performance. As WC is unpredictable and optional the HW designs all tolerate cases where combining doesn't happen and simply experience a performance degradation. Unfortunately many virtualization environments on all architectures have done things that completely disable WC inside the VM with no generic way to detect this. For example WC was fully blocked in ARM64 KVM until commit 8c47ce3 ("KVM: arm64: Set io memory s2 pte as normalnc for vfio pci device"). Trying to use WC when it is known not to work has a measurable performance cost (~5%). Long ago mlx5 developed an boot time algorithm to test if WC is available or not by using unique mlx5 HW features to measure how many large TLPs the device is receiving. The SW generates a large number of combining opportunities and if any succeed then WC is declared working. In mlx5 the WC optimization feature is never used by the kernel except for the boot time test. The WC is only used by userspace in rdma-core. Sadly modern ARM CPUs, especially NVIDIA Grace, have a combining implementation that is very unreliable compared to pretty much everything prior. This is being fixed architecturally in new CPUs with a new ST64B instruction, but current shipping devices suffer this problem. Unreliable means the SW can present thousands of combining opportunities and the HW will not combine for any of them, which creates a performance degradation, and critically fails the mlx5 boot test. However, the CPU is very sensitive to the instruction sequence used, with the better options being sufficiently good that the performance loss from the unreliable CPU is not measurable. Broadly there are several options, from worst to best: 1) A C loop doing a u64 memcpy. This was used prior to commit ef30228 ("IB/mlx5: Use __iowrite64_copy() for write combining stores") and failed almost all the time on Grace CPUs. 2) ARM64 assembly with consecutive 8 byte stores. This was implemented as an arch-generic __iowriteXX_copy() family of functions suitable for performance use in drivers for WC. commit ead7911 ("arm64/io: Provide a WC friendly __iowriteXX_copy()") provided the ARM implementation. 3) ARM64 assembly with consecutive 16 byte stores. This was rejected from kernel use over fears of virtualization failures. Common ARM VMMs will crash if STP is used against emulated memory. 4) A single NEON store instruction. Userspace has used this option for a very long time, it performs well. 5) For future silicon the new ST64B instruction is guaranteed to generate a 64 byte TLP 100% of the time The past upgrade from kernel-patches#1 to kernel-patches#2 was thought to be sufficient to solve this problem. However, more testing on more systems shows that kernel-patches#3 is still problematic at a low frequency and the kernel test fails. Thus, make the mlx5 use the same instructions as userspace during the boot time WC self test. This way the WC test matches the userspace and will properly detect the ability of HW to support the WC workload that userspace will generate. While kernel-patches#4 still has imperfect combining performance, it is substantially better than kernel-patches#2, and does actually give a performance win to applications. Self-test failures with kernel-patches#2 are like 3/10 boots, on some systems, kernel-patches#4 has never seen a boot failure. There is no real general use case for a NEON based WC flow in the kernel. This is not suitable for any performance path work as getting into/out of a NEON context is fairly expensive compared to the gain of WC. Future CPUs are going to fix this issue by using an new ARM instruction and __iowriteXX_copy() will be updated to use that automatically, probably using the ALTERNATES mechanism. Since this problem is constrained to mlx5's unique situation of needing a non-performance code path to duplicate what mlx5 userspace is doing as a matter of self-testing, implement it as a one line inline assembly in the driver directly. Lastly, this was concluded from the discussion with ARM maintainers which confirms that this is the best approach for the solution: https://lore.kernel.org/r/[email protected] Signed-off-by: Patrisious Haddad <[email protected]> Reviewed-by: Michael Guralnik <[email protected]> Reviewed-by: Moshe Shemesh <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Signed-off-by: NipaLocal <nipa@local>
The DPLL phase measurement block uses an exponential moving average,
calculated using the following equation:
2^N - 1 1
curr_avg = prev_avg * --------- + new_val * -----
2^N 2^N
Where curr_avg is phase offset reported by the firmware to the driver,
prev_avg is previous averaged value and new_val is currently measured
value for particular reference.
New measurements are taken approximately 40 Hz or at the frequency of
the reference (whichever is lower).
The driver currently uses the averaging factor N=2 which prioritizes
a fast response time to track dynamic changes in the phase. But for
applications requiring a very stable and precise reading of the average
phase offset, and where rapid changes are not expected, a higher factor
would be appropriate.
Add devlink device parameter phase_offset_avg_factor to allow a user
set tune the averaging factor via devlink interface.
Reviewed-by: Przemek Kitszel <[email protected]>
Tested-by: Prathosh Satish <[email protected]>
Signed-off-by: Ivan Vecera <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
Fix the bounds checks for the hw supported maximum GCL entry count and gate interval time. Fixes: b60189e ("net: stmmac: Integrate EST with TAPRIO scheduler API") Signed-off-by: Rohan G Thomas <[email protected]> Reviewed-by: Matthew Gerlach <[email protected]> Signed-off-by: NipaLocal <nipa@local>
On hardware with Tx VLAN offload enabled, add the VLAN tag length to the skb length before checking the Qbv maxSDU. Add 4 bytes for 802.1Q an add 8 bytes for 802.1AD tagging. Fixes: c5c3e1b ("net: stmmac: Offload queueMaxSDU from tc-taprio") Signed-off-by: Rohan G Thomas <[email protected]> Reviewed-by: Matthew Gerlach <[email protected]> Signed-off-by: NipaLocal <nipa@local>
This driver by now supports 17 different Microchip (formerly known as Micrel) chips: KSZ9021, KSZ9031, KSZ9131, KSZ8001, KS8737, KSZ8021, KSZ8031, KSZ8041, KSZ8051, KSZ8061, KSZ8081, KSZ8873MLL, KSZ886X, KSZ9477, LAN8814, LAN8804 and LAN8841. Support for the VSC8201 was removed in commit 51f932c ("micrel phy driver - updated(1)") Update the help text to reflect that, list families instead of models to ease future maintenance. Signed-off-by: Jonas Rebmann <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Drop those frames causing HLBS error to avoid HLBS interrupt flooding and netdev watchdog timeouts due to blocked packets. Also add HLBS frame drops to taprio stats. Signed-off-by: Rohan G Thomas <[email protected]> Reviewed-by: Matthew Gerlach <[email protected]> Signed-off-by: NipaLocal <nipa@local>
mv88e6250_ptp_ops and mv88e6352_ptp_ops are identical since commit 7e3c180 ("net: dsa: mv88e6xxx: read cycle counter period from hardware"). Remove the unnecessary duplication. Reviewed-by: Vadim Fedorenko <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
chip->trig_config is never written, and thus takes the value zero. Remove this struct member and its single reader. Reviewed-by: Vadim Fedorenko <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
evcap_config is only read and written in mv88e6352_config_eventcap(), so it makes little sense to store it in the global chip struct. Make it a local variable instead. Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
mv88e6352_config_eventcap() is documented as handling both EXTTS and PPS capture modes, but nothing ever calls it for PPS capture. Remove the unused PPS capture mode support, and the now unused MV88E6XXX_TAI_EVENT_STATUS_CAP_TRIG definition. Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
The ENA ethtool implementation mistakenly sets the Autoneg link mode twice in the 'supported' mask, leaving the 'advertising mask unset. Fix this by setting Autoneg in 'advertising' instead of duplicating it in 'supported'. Fixes: 1738cd3 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by: Alok Tiwari <[email protected]> Signed-off-by: NipaLocal <nipa@local>
We need to increment i_fastreg_wrs before we bail out from rds_ib_post_reg_frmr(). We have a fixed budget of how many FRWR operations that can be outstanding using the dedicated QP used for memory registrations and de-registrations. This budget is enforced by the atomic_t i_fastreg_wrs. If we bail out early in rds_ib_post_reg_frmr(), we will "leak" the possibility of posting an FRWR operation, and if that accumulates, no FRWR operation can be carried out. Fixes: 1659185 ("RDS: IB: Support Fastreg MR (FRMR) memory registration mode") Fixes: 3a2886c ("net/rds: Keep track of and wait for FRWR segments in use upon shutdown") Cc: [email protected] Signed-off-by: Håkon Bugge <[email protected]> Reviewed-by: Allison Henderson <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Let's see if this increases stability of timing-related results.. Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
These are unlikely to matter for CI testing and they slow things down. Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
tc_actions.sh keeps hanging the forwarding tests. sdf@: tdc & tdc-dbg started intermittenly failing around Sep 25th Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: NipaLocal <nipa@local>
We exclusively use headless VMs today, don't waste time compiling sound and GPU drivers. Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kmemleak auto scan could be a source of latency for the tests. We run a full scan after the tests manually, we don't need the autoscan thread to be enabled. Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reusable PR for hooking netdev CI to BPF testing.