| be00853b | 16-Jun-2022 |
Petr Machata <[email protected]> |
selftests: mlxsw: Add a RIF counter scale test
This tests creates as many RIFs as possible, ideally more than there can be
RIF counters (though that is currently only possible on Spectrum-1). It
the
selftests: mlxsw: Add a RIF counter scale test
This tests creates as many RIFs as possible, ideally more than there can be
RIF counters (though that is currently only possible on Spectrum-1). It
then tries to enable L3 HW stats on each of the RIFs. It also contains the
traffic test, which tries to run traffic through a log2 of those counters
and checks that the traffic is shown in the counter values.
Like with tc_flower traffic test, take a log2 subset of rules. The logic
behind picking log2 rules is that then every bit of the instantiated item's
number is exercised. This should catch issues whether they happen at the
high end, low end, or somewhere in between.
Signed-off-by: Petr Machata <[email protected]>
Reviewed-by: Amit Cohen <[email protected]>
Signed-off-by: Ido Schimmel <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
show more ...
|
| 35d5829e | 16-Jun-2022 |
Petr Machata <[email protected]> |
selftests: mlxsw: resource_scale: Pass target count to cleanup
The scale tests are verifying behavior of mlxsw when number of instances of
some resource reaches the ASIC capacity. The number of inst
selftests: mlxsw: resource_scale: Pass target count to cleanup
The scale tests are verifying behavior of mlxsw when number of instances of
some resource reaches the ASIC capacity. The number of instances is
referred to as "target" number.
No scale tests so far needed to know this target number to clean up. E.g.
the tc_flower simply removes the clsact qdisc that all the tested filters
are hooked onto, and that takes care of collecting all the filters.
However, for the RIF counter test, which is being added in a future patch,
VLAN netdevices are created. These are created as part of the test, but of
course the cleanup needs to undo them again. For that it needs to know how
many there were. To support this usage, pass the target number to the
cleanup callback.
Signed-off-by: Petr Machata <[email protected]>
Reviewed-by: Amit Cohen <[email protected]>
Signed-off-by: Ido Schimmel <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
show more ...
|
| 8cad339d | 16-Jun-2022 |
Petr Machata <[email protected]> |
selftests: mlxsw: resource_scale: Allow skipping a test
The scale tests are currently testing two things: that some number of
instances of a given resource can actually be created; and that when an
selftests: mlxsw: resource_scale: Allow skipping a test
The scale tests are currently testing two things: that some number of
instances of a given resource can actually be created; and that when an
attempt is made to create more than the supported amount, the failures are
noted and handled gracefully.
Sometimes the scale test depends on more than one resource. In particular,
a following patch will add a RIF counter scale test, which depends on the
number of RIF counters that can be bound, and also on the number of RIFs
that can be created.
When the test is limited by the auxiliary resource and not by the primary
one, there's no point trying to run the overflow test, because it would be
testing exhaustion of the wrong resource.
To support this use case, when the $test_get_target yields 0, skip the test
instead.
Signed-off-by: Petr Machata <[email protected]>
Reviewed-by: Amit Cohen <[email protected]>
Signed-off-by: Ido Schimmel <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
show more ...
|
| 3128b9f5 | 16-Jun-2022 |
Petr Machata <[email protected]> |
selftests: mlxsw: resource_scale: Introduce traffic tests
The scale tests are currently testing two things: that some number of
instances of a given resource can actually be created; and that when a
selftests: mlxsw: resource_scale: Introduce traffic tests
The scale tests are currently testing two things: that some number of
instances of a given resource can actually be created; and that when an
attempt is made to create more than the supported amount, the failures are
noted and handled gracefully.
However the ability to allocate the resource does not mean that the
resource actually works when passing traffic. For that, make it possible
for a given scale to also test traffic.
Traffic test is only run on the positive leg of the scale test (no point
trying to pass traffic when the expected outcome is that the resource will
not be allocated). Traffic tests are opt-in, if a given test does not
expose it, it is not run.
To this end, delay the test cleanup until after the traffic test is run.
Signed-off-by: Petr Machata <[email protected]>
Reviewed-by: Amit Cohen <[email protected]>
Signed-off-by: Ido Schimmel <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
show more ...
|