From: Simon Horman <horms@kernel•org>
To: Felix Maurer <fmaurer@redhat•com>
Cc: netdev@vger•kernel.org, davem@davemloft•net, edumazet@google•com,
kuba@kernel•org, pabeni@redhat•com, jkarrenpalo@gmail•com,
tglx@linutronix•de, mingo@kernel•org,
allison.henderson@oracle•com, matttbe@kernel•org,
petrm@nvidia•com, bigeasy@linutronix•de
Subject: Re: [RFC net 0/6] hsr: Implement more robust duplicate discard algorithm
Date: Tue, 6 Jan 2026 14:30:28 +0000 [thread overview]
Message-ID: <aV0chBkc20PCn-Is@horms.kernel.org> (raw)
In-Reply-To: <cover.1766433800.git.fmaurer@redhat.com>
On Mon, Dec 22, 2025 at 09:57:30PM +0100, Felix Maurer wrote:
> The PRP duplicate discard algorithm does not work reliably with certain
> link faults. Especially with packet loss on one link, the duplicate
> discard algorithm drops valid packets. For a more thorough description
> see patch 5.
>
> My suggestion is to replace the current, drop window-based algorithm
> with a new one that tracks the received sequence numbers individually
> (description again in patch 5). I am sending this as an RFC to gather
> feedback mainly on two points:
>
> 1. Is the design generally acceptable? Of course, this change leads to
> higher memory usage and more work to do for each packet. But I argue
> that this is an acceptable trade-off to make for a more robust PRP
> behavior with faulty links. After all, PRP is to be used in
> environments where redundancy is needed and people are ready to
> maintain two duplicate networks to achieve it.
> 2. As the tests added in patch 6 show, HSR is subject to similar
> problems. I do not see a reason not to use a very similar algorithm
> for HSR as well (with a bitmap for each port). Any objections to
> doing that (in a later patch series)? This will make the trade-off
> with memory usage more pronounced, as the hsr_seq_block will grow by
> three more bitmaps, at least for each HSR node (of which we do not
> expect too many, as an HSR ring can not be infinitely large).
Hi Felix,
Happy New Year!
We have spoken about this offline before and I agree that the situation
should be improved.
IMHO the trade-offs you are making here seem reasonable. And I wonder if
it helps to think in terms of the expected usage of this code: Is it
expected to scale to a point where the memory and CPU overhead becomes
unreasonable; or do, as I think you imply above, we expect deployments to
be on systems where the trade-offs are acceptable?
>
> Most of the patches in this series are for the selftests. This is mainly
> to demonstrate the problems with the current duplicate discard
> algorithms, not so much about gathering feedback. Especially patch 1 and
> 2 are rather preparatory cleanups that do not have much to do with the
> actual problems the new algorithm tries to solve.
>
> A few points I know not yet addressed are:
> - HSR duplicate discard (see above).
> - The KUnit test is not updated for the new algorithm. I will work on
> that before actual patch submission.
FTR, the KUnit tests no longer compiles. But probably you already knew that.
> - Merging the sequence number blocks when two entries in the node table
> are merged because they belong to the same node.
>
> Thank you for your feedback already!
Some slightly more specific feedback:
* These patches are probably for net-next rather than net
* Please run checkpatch.pl --max-line-length=80 --codespell (on each patch)
- And fix the line lengths where it doesn't reduce readability.
E.g. don't split strings
* Please also run shellcheck on the selftests
- As much as is reasonable please address the warnings
- In general new .sh files should be shellcheck-clean
- To aid this, use "# shellcheck disable=CASE", for cases that don't match
the way selftests are written , e.g. SC2154 and SC2034
* I was curious to see LANG=C in at least one of the selftests.
And I do see limited precedence for that. I'm just mentioning
that I was surprised as I'd always thought it was an implied requirement.
next prev parent reply other threads:[~2026-01-06 14:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-22 20:57 [RFC net 0/6] hsr: Implement more robust duplicate discard algorithm Felix Maurer
2025-12-22 20:57 ` [RFC net 1/6] selftests: hsr: Add ping test for PRP Felix Maurer
2025-12-22 20:57 ` [RFC net 2/6] selftests: hsr: Check duplicates on HSR with VLAN Felix Maurer
2025-12-22 20:57 ` [RFC net 3/6] selftests: hsr: Add tests for faulty links Felix Maurer
2025-12-22 20:57 ` [RFC net 4/6] selftests: hsr: Add tests for more link faults with PRP Felix Maurer
2025-12-22 20:57 ` [RFC net 5/6] hsr: Implement more robust duplicate discard for PRP Felix Maurer
2025-12-22 20:57 ` [RFC net 6/6] selftests: hsr: Add more link fault tests for HSR Felix Maurer
2026-01-06 14:30 ` Simon Horman [this message]
2026-01-08 13:44 ` [RFC net 0/6] hsr: Implement more robust duplicate discard algorithm Felix Maurer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aV0chBkc20PCn-Is@horms.kernel.org \
--to=horms@kernel$(echo .)org \
--cc=allison.henderson@oracle$(echo .)com \
--cc=bigeasy@linutronix$(echo .)de \
--cc=davem@davemloft$(echo .)net \
--cc=edumazet@google$(echo .)com \
--cc=fmaurer@redhat$(echo .)com \
--cc=jkarrenpalo@gmail$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=matttbe@kernel$(echo .)org \
--cc=mingo@kernel$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=petrm@nvidia$(echo .)com \
--cc=tglx@linutronix$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox