Zperf should use the optimal configuration

[Freey0]

Summary

For those who are interested in the performance of the Zephyr network, zperf is of great significance. It is a convenient and out-of-box method for testing network performance.

1. For UDP, The size of the package is highly sensitive to network performance. the maximum packet size is 1470 bytes (for IPv4) and 1450 bytes (for IPv6). We should use the maximum packet size.

This is also the default configuration of iperf, and it is also the recommended configuration for network performance testing in other RTOS systems.

2. For TCP, CONFIG_PICOLIBC_USE_MODULE=y has a significant impact on performance.

Use nucleo_h743zi board with loopback

before:
tcp upload: 49.35 Mbps/s

after:
tcp upload: 56.52 Mbps/s

Use nucleo_h743zi board, default config

before:
tcp upload: 71.3Mbps/s
tcp download: 75.11 Mbps/s

after:
tcp upload: 75.3Mbps/s
tcp download: 94.39 Mbps/s

Use nucleo_h743zi board, with tx async mode pr93965

before:
tcp upload: 71.3Mbps/s
tcp download: 75.11 Mbps/s

after:
tcp upload: 92.9Mbps/s
tcp download: 94.5Mbps/s

Describe the solution you'd like

1. Add to the prj.conf file of sample/net/zperf

# For speed optimizations
CONFIG_PICOLIBC_USE_MODULE=y
CONFIG_NET_ZPERF_MAX_PACKET_SIZE=1470

2. Update the zperf documentation and use the maximum packet size 1470 (IPv4) / 1450 (IPv6) instead of 1K.

3. zperf_shell.c, The help documentation for UDP upload cmd uses 1470 (for IPv4) and 1450 (for IPv6) instead of 1k.

Alternatives

No response

Additional Context

No response

[rlubos]

For NET_ZPERF_MAX_PACKET_SIZE, maybe we could just update the config default based on whether IPv4/6 are enabled.
Generally no objections, perhaps you could just send a PR with suggested changes?

[Freey0]

When updating the default configuration with NET_ZPERF_MAX_PACKET_SIZE, I am confused about what exactly MAX_PACKET_SIZE refers to.

Does it mean the size of the data? Does it mean the size of the (data + zperf header) ?

Examining the implementation of TCP and UDP, we can see that their meanings are not consistent either. TCP is the former, and UDP is the latter.

If MAX_PACKET_SIZE refers to the size of the data plus the zperf header. Setting it to 1470 is not appropriate. Instead, it should be reduced by the size of the zperf header.

[Freey0]

subsys/net/lib/zperf/zperf_tcp_uploader.c

static char sample_packet[PACKET_SIZE_MAX];

subsys/net/lib/zperf/zperf_udp_uploader.c

static uint8_t sample_packet[sizeof(struct zperf_udp_datagram) +
			     sizeof(struct zperf_client_hdr_v1) +
			     PACKET_SIZE_MAX];

[rlubos]

There seems to be indeed a difference in the protocol between UDP/TCP uploads, UDP adds extra headers before the data, while TCP not (I'm not familiar with the protocol very well so cannot comment any further, it doesn't seem to be documented well according to comments). But in both cases PACKET_SIZE_MAX seem to be referring to the overall UDP/TCP payload (including any additional headers), as it's limiting the packet size in both cases:

zephyr/subsys/net/lib/zperf/zperf_udp_uploader.c

Line 179 in d330e86

if (packet_size > PACKET_SIZE_MAX) {

That extra space in the packet buffer for UDP:

subsys/net/lib/zperf/zperf_udp_uploader.c

static uint8_t sample_packet[sizeof(struct zperf_udp_datagram) +
			     sizeof(struct zperf_client_hdr_v1) +
			     PACKET_SIZE_MAX];

I don't think it's actually needed, as the extra space won't be used anyway looking at the implementation.