Re: [PATCH net-next v2 5/9] selftests: hsr: Add tests for more link faults with PRP

[Felix Maurer <fmaurer@redhat.com>]

On Thu, Jan 29, 2026 at 02:32:17PM +0100, Sebastian Andrzej Siewior wrote:
> On 2026-01-22 15:57:00 [+0100], Felix Maurer wrote:
> > Add tests where one link has different rates of packet loss or reorders
> > packets. PRP should still be able to recover from these link faults and
> > show no packet loss.  However, it is acceptable to receive some level of
> > duplicate packets. This matches the current specification (IEC
> > 62439-3:2021) of the duplicate discard algorithm that requires it to be
> > "designed such that it never rejects a legitimate frame, while occasional
> > acceptance of a duplicate can be tolerated." The rate of acceptable
> > duplicates in this test is intentionally high (10%) to make the test
> > stable, the values I observed in the worst test cases (20% loss) are around
> > 5% duplicates.
>
> Do you know why we have the duplicates? It is because of the high
> sending rate at which point the blocks are dropped and we can't
> recognise the duplicate?

I could not give a definitive answer on this last week, I had to dig a
bit and think through this. The reason for the duplicates is not a high
sending rate leading to dropped blocks. Rather, it's the low sending
rate leading to expiring blocks: in the test, the ping interval is set
to 10ms. As the blocks expire based on the timestamp of the first
received sequence number, the 400ms entry expiry gets hit every ca. 40
frames, at which we basically clear all received sequence number in the
block by creating a new block. This happens on both nodes (for ping
requests and replies) ca. 10 times during the test, leading to about 20
duplicate packets, which is the ca. 5% duplicates I observed in multiple
runs of this test.

This means the duplicate rate is highly dependent on the traffic pattern
and the test manages to hit exactly this situation. I'll add the
explanation to the message in v3. If similar traffic patterns are hit in
the real world too often, we could test different block sizes. I just
did this and the results are as expected:
- 64 bit blocks: the duplicate rate is about the same because the block
  still expires once.
- 32 bit blocks: the duplicate rate drops to around 4% because,
  including the netem delay in the test, this is roughly the edge
  between expiring a block and already hitting a new one. But if we keep
  the bitmap as it is, we waste 50% of memory.
- 16 bit blocks: duplicate rate is zero because we use new blocks way
  before the expiry time. But this wastes about 75% memory for each
  block and the overhead of the timestamp in each block gets quite
  significant.

I'd suggest to keep the 128 bit blocks to have a chance to detect
duplicates at higher data rates for some delay difference (up to about
5.5ms with 1Gbit/s). 64 bit blocks would halve the maximum delay
difference, but probably still strike a good balance between memory
overhead and duplicate rate. Do you prefer one over the other?

Thanks,
   Felix