benchmark_udp: improve rtt record buffering

[elenaf9]

Contribution description

Small improvement when accessing the buffer that stores the records for pending pings.

There is no need to iterate through the buffer to find the oldest entry. The ping sequence number is linear and for each ping we add a record entry:

RIOT/sys/test_utils/benchmark_udp/benchmark_udp.c

Lines 124 to 134 in ef76a04

	while (running) {
	_put_rtt(ping->seq_no);
	if (sock_udp_send(&sock, ping, sizeof(*ping) + payload_size, &remote) < 0) {
	puts("Error sending message");
	continue;
	} else {
	unsigned state = irq_disable();
	ping->seq_no++;
	irq_restore(state);
	}

So modulo calculation can be used to get the index of the oldest/ next entry.

Testing procedure

Can be tested by running dist/tools/benchmark_udp (server) on the host and sys/test_utils/benchmark_udp (client) on a connected node.

Issues/PRs references

[riot-ci]

Murdock results

✔️ PASSED

1ce1834 benchmark_udp: improve rtt record buffering

Success	Failures	Total	Runtime
10515	0	10516	09m:51s

Artifacts

• Documentation preview

[benpicco]

The ping sequence number is linear

I'm not super familiar with the code anymore, but what if the receiver doesn't receive a ping message, wouldn't that cause a collision in the array when the next one arrives?

[elenaf9]

The ping sequence number is linear

I'm not super familiar with the code anymore, but what if the receiver doesn't receive a ping message, wouldn't that cause a collision in the array when the next one arrives?

The code is on the client side, i.e. the side that sends the pings and does the linear increase of the sequence number. So I don't think it matters whether the receiver actually receives the ping. Or do you mean sth else?
The only thing that can happen is that we receive an old pong with a sequence number for which we've already re-used the index, but we still have a check to catch that case.