Message-ID: <aYHg08WMQyQKmgZO@thinkpad>
Date: Tue, 3 Feb 2026 12:49:39 +0100
From: Felix Maurer <fmaurer@...hat.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
	kuba@...nel.org, pabeni@...hat.com, horms@...nel.org,
	jkarrenpalo@...il.com, tglx@...utronix.de, mingo@...nel.org,
	allison.henderson@...cle.com, petrm@...dia.com, antonio@...nvpn.net,
	Yoann Congal <yoann.congal@...le.fr>
Subject: Re: [PATCH net-next v2 6/9] hsr: Implement more robust duplicate
 discard for HSR

On Mon, Feb 02, 2026 at 06:53:11PM +0100, Sebastian Andrzej Siewior wrote:
> 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.

I agree, it looks like a failure. I tried to find the reason why the
standard is so explicitly asking for discarding duplicates within the
ring, as that implies that sometimes such duplicates happen in normal
operation. In most cases, IMHO, there should not be any duplicates in
the same direction in the ring, if the nodes behave correctly.

I think the duplicates can occur on RedBoxes if they are used to couple
the HSR ring and another redundant network (either with a PRP network
through HSR-PRP mode or with an HSR network through HSR-HSR mode, which
we both don't implement at the moment). In both cases, two RedBoxes are
used to maintain redundancy and both independently inject a frame they
receive into the HSR ring (see Figure 12 and 16 in the IEC
62439-3:2021). But it's also the RedBoxes that would remove the
duplicates, so we would be aware that we should discard duplicates on
port A and B.

However, I'm not sure if these are the only cases where duplicates are
to be expected in the ring and I don't want to prematurely make the
decision to just forward everything within the ring.

> If you track duplicates for A and B in a single "bitmap" then this would
> mode X.

I think I didn't understand this clearly and I mixed this up in some of
my replies, so just to make sure; there are two ideas:
1) Track port A and B together, i.e., don't forward the
   counter-duplicate, i.e., Mode X (which is optional to implement).
2) Don't track duplicates for port A or B at all. We consider duplicates
   in the ring as a failure of another node.

We don't consider 1), i.e., Mode X, at the moment. We are only
discussing idea 2), right?

> 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.

I totally understand that. It's quite some memory for each node and I'm
very much in for reducing that. But I'd suggest that, for now, we follow
what we had before and what the standard explicitly asks, which is to
track (and discard) duplicates on port A and B as well. I'm not sure if
we should diverge from the standard in one of the few points where it is
explicit. If I understand your last sentence correctly, you're okay with
that as well?

Thanks,
   Felix

Powered by blists - more mailing lists