Re: [PATCH bpf-next v4 3/3] selftests/bpf: Support nonblock for send_recv_data

[Matthieu Baerts <matttbe@kernel.org>]

On 22/04/2024 12:04, Geliang Tang wrote:> On Mon, 2024-04-22 at 11:45
+0200, Matthieu Baerts wrote:

(...)

>> I might be wrong, but with MPTCP schedulers, it is different: with
>> non-blocking IO, EAGAIN can be seen, and this case needs to be
>> handled.
>> Actively waiting by retrying directly in the loop in case of EAGAIN
>> is
>> not recommended, but probably OK for the tests (still, might be good
>> to
>> add a comment to recommend polling instead). So here as well, such
>> modifications can stay in our tree for the moment.
>>
>> Also, what is not clear to me is where we set the socket as the
>> non-blocking one. Is it only done for MPTCP servers/clients?
> 
> I didn't set the socket as non-block in the end.
> 
> EAGAIN will be got no matter non-block flag is set or not.

That's strange, no? When the userspace sends data with a blocking IO
socket, it should not get EAGAIN, no?

> In old version like "[mptcp-next,v7,0/5] setsockopt per subflow: BPF":
> 
> https://patchwork.kernel.org/project/mptcp/cover/cover.1712571740.git.tanggeliang@kylinos.cn/
> 
> "set_nonblock" is added in patch 2, and invoked in run_subflow() in
> patch 3.

I see, but the commit message of patch 2 doesn't explain why
set_nonblock() is needed for MPTCP. I see it is used in patch 3, but is
it really necessary? Maybe it was added for other reasons, that are no
longer valid today?

>>> I added a issue #487 to trace this issue.

Please also note that we didn't have this issue for a while. When we had
it, it is when KVM was not supported on the CI:

 $ /opt/virtme/virtme-run (...)
 Could not access KVM kernel module: No such file or directory
 qemu-system-x86_64: failed to initialize kvm: No such file or directory
 qemu-system-x86_64: falling back to tcg


Maybe we had this issue because the VM was abnormally too slow, and we
reached the 3 seconds timeout described by Martin in a previous message?
If this is due to the "abnormally slow setup", maybe we don't need to do
anything?

In other words, can you (easily) reproduce the issue on your side? With
or without KVM support?

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.