Skip to content

Conversation

@schlad
Copy link
Contributor

@schlad schlad commented Sep 3, 2025

This is a minimal, test-only tweak to stabilize results across different arches without changing test logic.

IMHO, ideally we would find a way to allocate the buffer based on the system under test runtime socket SO_RCVBUF, so we would have a test without the hardcoded RECV_BIDS and thus the buffer size.

So while I do not have a ready patch/solution, I wanted to see what do you think about it.

… on ppc64

Sub-test (d) "bundling with full socket" pre-fills the peer until EAGAIN.
On some architectures (like ppc64), once the tcp_w/rmem min is set to higher
value, like 64k and with autotuning on, the sender can queue more than the
1MiB before the receiver arms multishot recv. With a 1MiB provided-buffer
pool (MSG_SIZE * RECV_BIDS, so 8192 * 128), the first recv runs out of
provided buffers and fails with -105 (ENOBUFS).

Bump RECV_BIDS from 8192 to 16384, so the pool no longer underflows
during the prefill on ppc64. This is a minimal, test-only tweak to
stabilize results across different arches without changing test logic.

Signed-off-by: Sebastian Chlad <sebastian.chlad@suse.com>
@axboe
Copy link
Owner

axboe commented Sep 3, 2025

I think that work-around is likely just fine.

@axboe axboe merged commit 66e2888 into axboe:master Sep 3, 2025
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants