Re: [PATCH net-next v2 6/9] hsr: Implement more robust duplicate discard for HSR

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-01-30 11:34:55 [+0100], Felix Maurer wrote:
> I took another look at this. I think the IEC 62439-3:2021 is not super
> clear on this (it often refers to "duplicate frames" without being exact
> about in which domain they are duplicates). But the section on HSR Modes
> (5.3.2.1) is quite telling when all modes are read in combination.
> 
> First, there is the mode H, which is the default and mandatory to
> implement. In this mode, a node should forward all frames "except for
> frames sent by the node itself, duplicate frames and frames for which
> the node is the unique destination". Note that "duplicate frame" is not
> further specified here. As we don't implement different modes, we should
> follow mode H in our implementation.
> 
> In contrast, there is also mode X (sometimes referred to as "traffic
> reduction").  It is supposed to work like mode H, but without sending
> "counter-duplicates", i.e., frames that are "a duplicate of a frame that
> it received [...] from the opposite direction."
> 
> To me, this means two things for mode H, i.e., what we should be doing:
> - For a frame with one sequence number coming from one node, we should
>   be forwarding the frame once in each direction.
> - There could be duplicates of these frames in either direction that we
>   should not forward. This is also hinted at in other parts of the
>   standard, that there could be multiple duplicates, especially when HSR
>   rings are coupled.
> 
> Therefore, I think it is correct to do the duplicate tracking once for
> each port, especially separately for port A and port B.

I will not argue with you here.
But. :)
If you track duplicates for A and B and see a duplicate on port A then
this indicates that the sender of this packet did not remove it from the
ring once it received it back. This looks like a failure.
If you track duplicates for A and B in a single "bitmap" then this would
mode X.

I nag here a bit because you allocate 16 + (128 / 8) * 4 * 64 = 4112
bytes for this bitmap per node. That is a bit over 4kib. Then adding and
removing sequences got a bit more expensive. Anyway. There is table
F.19+ specifying HSR tests and don't find "forwarding duplicate over
port A". So lets keep it.

> Thanks,
>    Felix

Sebastian