Branch: refs/heads/fast-link-up-stable1-proposed Home: https://github.com/kronosnet/kronosnet Commit: cbab84f47095ca51391157d36859f0548889fefd https://github.com/kronosnet/kronosnet/commit/cbab84f47095ca51391157d36859f0... Author: Fabio M. Di Nitto fdinitto@redhat.com Date: 2023-09-19 (Tue, 19 Sep 2023)

Changed paths: M libknet/links.c M libknet/tests/api_knet_link_set_ping_timers.c

Log Message: ----------- links: fix ping interval and pong timeout value checking

warn if ping internval is lower than thread time resolution as it has no effects

error if point timeout is lower than thread time resoltuion as it causes links to be highly unstable

Signed-off-by: Fabio M. Di Nitto fdinitto@redhat.com

Commit: f0843b5a4f81e5637a2e7ef4c5b3b6222ada6bcf https://github.com/kronosnet/kronosnet/commit/f0843b5a4f81e5637a2e7ef4c5b3b6... Author: Fabio M. Di Nitto fdinitto@redhat.com Date: 2023-09-19 (Tue, 19 Sep 2023)

Changed paths: M libknet/threads_rx.c

Log Message: ----------- rx: allow links to be active faster

scenario: node A and node B

node A completes ping/pong link up process faster than B node A starts to send data to node B

old behavior: node B would unconditionally discard data packets

new behavior: node B will check internal link status to see if ping/pong link up process is in progress.

if the link is sending pings and receiving pongs, it´s safe to assume that the link will go up (since we are also receiving data from the node A). node B will speed up link up and accept data immediately.

This should address a overall init race condition when nodes startup are slighly off by enough milliseconds to cause 2 memeberships to form and see fencing fireworks.

Signed-off-by: Fabio M. Di Nitto fdinitto@redhat.com

Compare: https://github.com/kronosnet/kronosnet/compare/cbab84f47095%5E...f0843b5a4f8...