[net-next,mlxsw,v3,09/10] selftests: forwarding: lib: Add lldpad waiting functions

Commit Message

Petr Machata July 27, 2018, 7:10 p.m. UTC

lldpad can sometimes take a long time to push the configured values to
the kernel. In the mean time they are stuck in pending state. Add a new
function, lldpad_wait_set(), to wait until all values that have been set
are pushed.

The situation is similar for deletes, where however there is no good
indication of whether the values are pending. Just sleep 5, which seems
to be enough time for lldpad to consistently update the kernel. (Unlike
in previous case, where the delay is often in the 30s ballpark.)

Signed-off-by: Petr Machata <[e-mail]>
---
 tools/testing/selftests/net/forwarding/lib.sh | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

Patch

diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
index d396f89d864d..abdcae9dc5c7 100644
--- a/tools/testing/selftests/net/forwarding/lib.sh
+++ b/tools/testing/selftests/net/forwarding/lib.sh
@@ -242,6 +242,27 @@  setup_wait()
 	sleep $WAIT_TIME
 }
 
+lldpad_wait_set()
+{
+	local dev=$1; shift
+
+	while lldptool -t -i $dev -V APP -c app | grep -q pending; do
+		echo "$dev: waiting for lldpad to push pending APP updates"
+		sleep 5
+	done
+}
+
+lldpad_wait_del()
+{
+	# Give lldpad a chance to push down the changes. If the device is downed
+	# too soon, the updates will be left pending. However, they will have
+	# been struck off the lldpad's DB already, so we won't be able to tell
+	# they are pending. Then on next test iteration this would cause
+	# weirdness as newly-added APP rules conflict with the old ones,
+	# sometimes getting stuck in an "unknown" state.
+	sleep 5
+}
+
 pre_cleanup()
 {
 	if [ "${PAUSE_ON_CLEANUP}" = "yes" ]; then