From: Matthieu Baerts <matttbe@kernel.org>
To: Geliang Tang <geliang@kernel.org>
Cc: mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next] Squash to "selftests/bpf: Add mptcp subflow subtest"
Date: Sun, 12 May 2024 14:42:34 +0200 (GMT+02:00) [thread overview]
Message-ID: <fd4359ab-f30a-468d-96f4-df43e34a3f81@kernel.org> (raw)
In-Reply-To: <ZkCrxpnEvIeYACTQ@T480>
12 May 2024 13:45:15 Geliang Tang <geliang@kernel.org>:
> On Sun, May 12, 2024 at 11:14:38AM +0200, Matthieu Baerts wrote:
>> Hi Geliang,
>>
>> 12 May 2024 01:17:13 Geliang Tang <geliang@kernel.org>:
>>> On Sat, May 11, 2024 at 03:50:29PM +0200, Matthieu Baerts wrote:
>>>> 11 May 2024 12:42:08 Geliang Tang <geliang@kernel.org>:
>>>>> From: Geliang Tang <tanggeliang@kylinos.cn>
>>
>> (...)
>>
>>>>> @@ -0,0 +1 @@
>>>>> +../net/mptcp/pm_nl_ctl.c
>>>>> \ No newline at end of file
>>>>> diff --git a/tools/testing/selftests/bpf/prog_tests/mptcp.c b/tools/testing/selftests/bpf/prog_tests/mptcp.c
>>>>> index 793b4b9c2bd2..9c6d1e4f6f35 100644
>>>>> --- a/tools/testing/selftests/bpf/prog_tests/mptcp.c
>>>>> +++ b/tools/testing/selftests/bpf/prog_tests/mptcp.c
>>>>> @@ -362,7 +362,8 @@ static int endpoint_init(char *flags)
>>>>> SYS(fail, "ip -net %s link set dev veth1 up", NS_TEST);
>>>>> SYS(fail, "ip -net %s addr add %s/24 dev veth2", NS_TEST, ADDR_2);
>>>>> SYS(fail, "ip -net %s link set dev veth2 up", NS_TEST);
>>>>> - SYS(fail, "ip -net %s mptcp endpoint add %s %s", NS_TEST, ADDR_2, flags);
>>>>> + if (SYS_NOFAIL("ip -net %s mptcp endpoint add %s %s", NS_TEST, ADDR_2, flags))
>>>>
>>>> It is maybe better to only use mptcp_pm_nl_ctl here: to maintain one way here, our CI will do the same as what the BPF one will do, and we avoid errors printed in stderr if "ip mptcp" is not supported.
>>>>
>>>
>>> No, I prefer this one. "ip mptcp" should be used here since it's
>>> the normal way to set mptcp. pm_nl_ctl is just a work-around for it.
>>>
>>> No error printed in stderr if "ip mptcp" is not supported since
>>> SYS_NOFAIL is used here, not SYS. I have tested this case already.
>>
>> SYS_NOFAIL doesn't redirect stderr to /dev/null, does it?
>> If "ip mptcp" is not supported and a fatal error happens, will you not see
>> in the logs "ip mptcp is not supported" as well, creating confusions?
>>
>> I would also prefer to use "ip mptcp" if available, but my main reason to
>> use only the workaround, is: if we change the syntax of pm_nl_ctl, not
>> realising we have to modify the code here as well, our CI will not
>> complain, but BPF CI will later, likely when validating something else.
>> We want our CI to catch such issues before upstreaming patches.
>>
>> Why not adding a comment instead?
>>
>> /* Equivalent of: "ip -net %s mptcp endpoint add %s %s" */
>>
>> So people interested in knowing how to do that the "proper" way will see
>> what to do, no?
>
> SYS_NOFAIL is defined in test_progs.h:
>
> 388 #define ALL_TO_DEV_NULL " >/dev/null 2>&1"
> 389
> 390 #define SYS_NOFAIL(fmt, ...) \
> 391 ({ \
> 392 char cmd[1024]; \
> 393 int n; \
> 394 n = snprintf(cmd, sizeof(cmd), fmt, ##__VA_ARGS__); \
> 395 if (n < sizeof(cmd) && sizeof(cmd) - n >= sizeof(ALL_TO_DEV_NULL)) \
> 396 strcat(cmd, ALL_TO_DEV_NULL); \
> 397 system(cmd); \
> 398 })
>
> See ALL_TO_DEV_NULL here.
My bad, I was looking at the code from v6.8.
But still, I think it would be better to avoid sending patches upstream
and potentially breaking stuff on BPF side because we didn't test
the same way as what is done on their side, no?
>
>>
>>>
>>>>> + SYS(fail, "ip netns exec %s ./pm_nl_ctl add %s flags %s", NS_TEST, ADDR_2, flags);
>>>>>
>>>>> return 0;
>>>>> fail:
>>>>> @@ -371,16 +372,8 @@ static int endpoint_init(char *flags)
>>>>>
>>>>> static int _ss_search(char *src, char *dst, char *port, char *keyword)
>>>>> {
>>>>> - char cmd[128];
>>>>> - int n;
>>>>> -
>>>>> - n = snprintf(cmd, sizeof(cmd),
>>>>> - "ip netns exec %s ss -Menita src %s dst %s %s %d | grep -q '%s'",
>>>>> - NS_TEST, src, dst, port, PORT_1, keyword);
>>>>> - if (n < 0 || n >= sizeof(cmd))
>>>>> - return -1;
>>>>> -
>>>>> - return system(cmd);
>>>>> + return SYS_NOFAIL("ip netns exec %s ss -Menita src %s dst %s %s %d | grep -q '%s'",
>>>>> + NS_TEST, src, dst, port, PORT_1, keyword);
>>>>
>>>> If "ip mptcp" is not supported, I guess "ss -M" will not be supported as well, no?
>>>>
>>>> Do we need -M here for these tests?
>>>
>>> No need to do this yet until we actually encounter it.
>>
>> "-e" is not needed as well I think. Don't hesitate to remove it as well.
>
> "-e" is needed by has_bytes_sent:
>
> 458 static int has_bytes_sent(char *dst)
> 459 {
> 460 return _ss_search(ADDR_1, dst, "sport", "bytes_sent:");
> 461 }
>
> BPF sched tests fail if remove it.
Thank you for having checked! It looks like ss' man page is missing
this case.
Cheers,
Matt
prev parent reply other threads:[~2024-05-12 12:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-11 10:41 [PATCH mptcp-next] Squash to "selftests/bpf: Add mptcp subflow subtest" Geliang Tang
2024-05-11 11:34 ` MPTCP CI
2024-05-11 13:50 ` Matthieu Baerts
2024-05-11 23:17 ` Geliang Tang
2024-05-12 9:14 ` Matthieu Baerts
2024-05-12 11:45 ` Geliang Tang
2024-05-12 12:42 ` Matthieu Baerts [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fd4359ab-f30a-468d-96f4-df43e34a3f81@kernel.org \
--to=matttbe@kernel.org \
--cc=geliang@kernel.org \
--cc=mptcp@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).