From: Geliang Tang <geliang@kernel.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Matthieu Baerts <matttbe@kernel.org>
Cc: MPTCP Upstream <mptcp@lists.linux.dev>,
Mat Martineau <martineau@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Mykola Lysenko <mykolal@fb.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, Shuah Khan <shuah@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
bpf <bpf@vger.kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
Geliang Tang <tanggeliang@kylinos.cn>
Subject: Re: [PATCH bpf-next 2/4] selftests/bpf: Add RUN_MPTCP_TEST macro
Date: Sat, 11 May 2024 09:42:30 +0800 [thread overview]
Message-ID: <d1361cc9104390c1d5971e4618934dbe942fae92.camel@kernel.org> (raw)
In-Reply-To: <CAADnVQJM73g9gTq3GxR-RMmpJPK3DGgzUTQiJXjz_B1G_4JAAw@mail.gmail.com>
On Tue, 2024-05-07 at 13:51 -0700, Alexei Starovoitov wrote:
> On Tue, May 7, 2024 at 9:02 AM Matthieu Baerts <matttbe@kernel.org>
> wrote:
> >
> > Hi Alexei,
> >
> > Thank you for the review!
> >
> > On 07/05/2024 16:44, Alexei Starovoitov wrote:
> > > On Tue, May 7, 2024 at 3:53 AM Matthieu Baerts (NGI0)
> > > <matttbe@kernel.org> wrote:
> > > >
> > > > From: Geliang Tang <tanggeliang@kylinos.cn>
> > > >
> > > > Each MPTCP subtest tests test__start_subtest(suffix), then
> > > > invokes
> > > > test_suffix(). It makes sense to add a new macro RUN_MPTCP_TEST
> > > > to
> > > > simpolify the code.
> > > >
> > > > Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
> > > > Reviewed-by: Mat Martineau <martineau@kernel.org>
> > > > Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> > > > ---
> > > > tools/testing/selftests/bpf/prog_tests/mptcp.c | 12 ++++++++--
> > > > --
> > > > 1 file changed, 8 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/tools/testing/selftests/bpf/prog_tests/mptcp.c
> > > > b/tools/testing/selftests/bpf/prog_tests/mptcp.c
> > > > index baf976a7a1dd..9d1b255bb654 100644
> > > > --- a/tools/testing/selftests/bpf/prog_tests/mptcp.c
> > > > +++ b/tools/testing/selftests/bpf/prog_tests/mptcp.c
> > > > @@ -347,10 +347,14 @@ static void test_mptcpify(void)
> > > > close(cgroup_fd);
> > > > }
> > > >
> > > > +#define RUN_MPTCP_TEST(suffix)
> > > > \
> > > > +do {
> > > > \
> > > > + if (test__start_subtest(#suffix))
> > > > \
> > > > + test_##suffix();
> > > > \
> > > > +} while (0)
> > >
> > > Please no.
> > > Don't hide it behind macros.
> >
> > I understand, I'm personally not a big fan of hiding code being a
> > macro
> > too. This one saves only one line. Geliang added a few more tests
> > in our
> > tree [1], for a total of 9, so that's only saving 9 lines.
> >
> > Related to that, if you don't mind, Geliang also added another
> > macro --
> > MPTCP_SCHED_TEST -- for tests that are currently only in our tree
> > [2]
> > (not ready yet). We asked him to reduce the size of this macro to
> > the
> > minimum. We accepted it because it removed quite a lot of similar
> > code
> > with very small differences [3]. Do you think we should revert this
> > modification too?
>
> Yeah. Pls don't hide such things in macros.
> Refactor into helper function in normal C.
I do agree to remove this RUN_MPTCP_TEST macro. But MPTCP_SCHED_TEST
macro is different. I know this type of macro is unwelcome. But it's
indeed a perfect place to use macro in MPTCP bpf sched tests.
From
'''
static void test_first(void)
{
struct mptcp_bpf_first *skel;
skel = mptcp_bpf_first__open_and_load();
if (!ASSERT_OK_PTR(skel, "open_and_load: first"))
return;
test_bpf_sched(skel->obj, "first", WITH_DATA, WITHOUT_DATA);
mptcp_bpf_first__destroy(skel);
}
static void test_bkup(void)
{
struct mptcp_bpf_bkup *skel;
skel = mptcp_bpf_bkup__open_and_load();
if (!ASSERT_OK_PTR(skel, "open_and_load: bkup"))
return;
test_bpf_sched(skel->obj, "bkup", WITH_DATA, WITHOUT_DATA);
mptcp_bpf_bkup__destroy(skel);
}
static void test_rr(void)
{
struct mptcp_bpf_rr *skel;
skel = mptcp_bpf_rr__open_and_load();
if (!ASSERT_OK_PTR(skel, "open_and_load: rr"))
return;
test_bpf_sched(skel->obj, "rr", WITH_DATA, WITH_DATA);
mptcp_bpf_rr__destroy(skel);
}
static void test_red(void)
{
struct mptcp_bpf_red *skel;
skel = mptcp_bpf_red__open_and_load();
if (!ASSERT_OK_PTR(skel, "open_and_load: red"))
return;
test_bpf_sched(skel->obj, "red", WITH_DATA, WITH_DATA);
mptcp_bpf_red__destroy(skel);
}
static void test_burst(void)
{
struct mptcp_bpf_burst *skel;
skel = mptcp_bpf_burst__open_and_load();
if (!ASSERT_OK_PTR(skel, "open_and_load: burst"))
return;
test_bpf_sched(skel->obj, "burst", WITH_DATA, WITH_DATA);
mptcp_bpf_burst__destroy(skel);
}
static void test_stale(void)
{
struct mptcp_bpf_stale *skel;
skel = mptcp_bpf_stale__open_and_load();
if (!ASSERT_OK_PTR(skel, "open_and_load: stale"))
return;
test_bpf_sched(skel->obj, "stale", WITH_DATA, WITHOUT_DATA);
mptcp_bpf_stale__destroy(skel);
}
'''
to
'''
#define MPTCP_SCHED_TEST(sched, addr1, addr2) \
static void test_##sched(void) \
{ \
struct mptcp_bpf_##sched *skel; \
\
skel = mptcp_bpf_##sched##__open_and_load(); \
if (!ASSERT_OK_PTR(skel, "open_and_load:" #sched)) \
return; \
\
test_bpf_sched(skel->obj, #sched, addr1, addr2); \
mptcp_bpf_##sched##__destroy(skel); \
}
MPTCP_SCHED_TEST(first, WITH_DATA, WITHOUT_DATA);
MPTCP_SCHED_TEST(bkup, WITH_DATA, WITHOUT_DATA);
MPTCP_SCHED_TEST(rr, WITH_DATA, WITH_DATA);
MPTCP_SCHED_TEST(red, WITH_DATA, WITH_DATA);
MPTCP_SCHED_TEST(burst, WITH_DATA, WITH_DATA);
MPTCP_SCHED_TEST(stale, WITH_DATA, WITHOUT_DATA);
'''
We can save so many code, and perfectly use BPF test skeleton template.
It's small enough, and be difficult to refactor with a helper function
in normal C.
Please reconsider whether to delete it, or at least keep it until the
day it is officially sent to BPF mail list for review.
Thanks,
-Geliang
>
> But, what do you mean "in your tree" ?
> That's your development tree and you plan to send all that
> properly as patches to bpf-next someday?
>
> >
> > [1]
> > https://github.com/multipath-tcp/mptcp_net-next/blob/4369d9cbd752e166961ac0db7f85886111606301/tools/testing/selftests/bpf/prog_tests/mptcp.c#L578-L595
> >
> > [2]
> > https://github.com/multipath-tcp/mptcp_net-next/blob/4369d9cbd752e166961ac0db7f85886111606301/tools/testing/selftests/bpf/prog_tests/mptcp.c#L559-L576
> >
> > [3]
> > https://lore.kernel.org/mptcp/cover.1713321357.git.tanggeliang@kylinos.cn/T/#m0b9c14f1cbae8653c6fd119f6b71d1797961d6ba
> >
> > Cheers,
> > Matt
> > --
> > Sponsored by the NGI0 Core fund.
> >
next prev parent reply other threads:[~2024-05-11 1:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-07 10:53 [PATCH bpf-next 0/4] selftests/bpf: new MPTCP subflow subtest & improvements Matthieu Baerts (NGI0)
2024-05-07 10:53 ` [PATCH bpf-next 1/4] selftests/bpf: Handle SIGINT when creating netns Matthieu Baerts (NGI0)
2024-05-07 14:43 ` Alexei Starovoitov
2024-05-07 15:59 ` Matthieu Baerts
2024-05-07 10:53 ` [PATCH bpf-next 2/4] selftests/bpf: Add RUN_MPTCP_TEST macro Matthieu Baerts (NGI0)
2024-05-07 14:44 ` Alexei Starovoitov
2024-05-07 16:02 ` Matthieu Baerts
2024-05-07 20:51 ` Alexei Starovoitov
2024-05-08 7:36 ` Matthieu Baerts
2024-05-11 1:42 ` Geliang Tang [this message]
2024-05-07 10:53 ` [PATCH bpf-next 3/4] selftests/bpf: Add mptcp subflow example Matthieu Baerts (NGI0)
2024-05-07 14:49 ` Alexei Starovoitov
2024-05-07 16:03 ` Matthieu Baerts
2024-05-07 20:54 ` Alexei Starovoitov
2024-05-08 7:36 ` Matthieu Baerts
2024-05-08 14:32 ` Alexei Starovoitov
2024-05-07 10:53 ` [PATCH bpf-next 4/4] selftests/bpf: Add mptcp subflow subtest Matthieu Baerts (NGI0)
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=d1361cc9104390c1d5971e4618934dbe942fae92.camel@kernel.org \
--to=geliang@kernel.org \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=martineau@kernel.org \
--cc=matttbe@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=mykolal@fb.com \
--cc=netdev@vger.kernel.org \
--cc=sdf@google.com \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=tanggeliang@kylinos.cn \
--cc=yonghong.song@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).