Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34 |
|
#
bef68e20 |
| 12-Jun-2023 |
Danielle Ratson <danieller@nvidia.com> |
selftests: forwarding: hw_stats_l3: Set addrgenmode in a separate step
Setting the IPv6 address generation mode of a net device during its creation never worked, but after commit b0ad3c179059 ("rtne
selftests: forwarding: hw_stats_l3: Set addrgenmode in a separate step
Setting the IPv6 address generation mode of a net device during its creation never worked, but after commit b0ad3c179059 ("rtnetlink: call validate_linkmsg in rtnl_create_link") it explicitly fails [1]. The failure is caused by the fact that validate_linkmsg() is called before the net device is registered, when it still does not have an 'inet6_dev'.
Likewise, raising the net device before setting the address generation mode is meaningless, because by the time the mode is set, the address has already been generated.
Therefore, fix the test to first create the net device, then set its IPv6 address generation mode and finally bring it up.
[1] # ip link add name mydev addrgenmode eui64 type dummy RTNETLINK answers: Address family not supported by protocol
Fixes: ba95e7930957 ("selftests: forwarding: hw_stats_l3: Add a new test") Signed-off-by: Danielle Ratson <danieller@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/f3b05d85b2bc0c3d6168fe8f7207c6c8365703db.1686580046.git.petrm@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
show more ...
|
Revision tags: v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23 |
|
#
a9fda7a0 |
| 05-Apr-2023 |
Petr Machata <petrm@nvidia.com> |
selftests: forwarding: hw_stats_l3: Detect failure to install counters
Running this test makes little sense if the enabled l3_stats are not actually reported as "used". This can signify a failure of
selftests: forwarding: hw_stats_l3: Detect failure to install counters
Running this test makes little sense if the enabled l3_stats are not actually reported as "used". This can signify a failure of a driver to install the necessary counters, or simply lack of support for enabling in-HW counters on a given netdevice. It is generally impossible to tell from the outside which it is. But more likely than not, if somebody is running this on veth pairs, they do not intend to actually test that a certain piece of HW can install in-HW counters for the veth. It is more likely they are e.g. running the test by mistake.
Therefore detect that the counter has not been actually installed. In that case, if the netdevice is one end of a veth pair, SKIP. Otherwise FAIL.
Suggested-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Tested-by: Hangbin Liu <liuhangbin@gmail.com> Link: https://lore.kernel.org/r/a86817961903cca5cb0aebf2b2a06294b8aa7dea.1680704172.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
Revision tags: v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38 |
|
#
32fb67a3 |
| 08-May-2022 |
Petr Machata <petrm@nvidia.com> |
selftests: lib: Add a generic helper for obtaining HW stats
The function get_l3_stats() from the test hw_stats_l3.sh will be useful for any test that wishes to work with L3 stats. Furthermore, it is
selftests: lib: Add a generic helper for obtaining HW stats
The function get_l3_stats() from the test hw_stats_l3.sh will be useful for any test that wishes to work with L3 stats. Furthermore, it is easy to generalize to other HW stats suites (for when such are added). Therefore, move the code to lib.sh, rewrite it to have the same interface as the other stats-collecting functions, and generalize to take the name of the HW stats suite to collect as an argument.
Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27 |
|
#
ba95e793 |
| 02-Mar-2022 |
Petr Machata <petrm@nvidia.com> |
selftests: forwarding: hw_stats_l3: Add a new test
Add a test that verifies operation of L3 HW statistics.
Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.
selftests: forwarding: hw_stats_l3: Add a new test
Add a test that verifies operation of L3 HW statistics.
Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|