[PATCH bpf-next v11 2/5] selftests/bpf: Use random netns name for mptcp
Geliang Tang
geliang.tang at suse.com
Wed Aug 9 08:19:44 UTC 2023
On Tue, Aug 08, 2023 at 11:03:30PM -0700, Martin KaFai Lau wrote:
> On 8/6/23 11:40 PM, Geliang Tang wrote:
> > On Fri, Aug 04, 2023 at 05:23:32PM -0700, Martin KaFai Lau wrote:
> > > On 8/3/23 10:07 PM, Geliang Tang wrote:
> > > > Use rand() to generate a random netns name instead of using the fixed
> > > > name "mptcp_ns" for every test.
> > > >
> > > > By doing that, we can re-launch the test even if there was an issue
> > > > removing the previous netns or if by accident, a netns with this generic
> > > > name already existed on the system.
> > > >
> > > > Note that using a different name each will also help adding more
> > > > subtests in future commits.
> >
> > Hi Martin,
> >
> > I tried to run mptcp tests simultaneously, and got "Cannot create
> > namespace file "/var/run/netns/mptcp_ns": File exists" errors sometimes.
> > So I add this patch to fix it.
> >
> > It's easy to reproduce, just run this commands in multiple terminals:
> > > for i in `seq 1 100`; do sudo ./test_progs -t mptcp; done
>
> Not only the "-t mptcp" test. Other tests in test_progs also don't support
> running parallel in multiple terminals. Does it really help to test the bpf
> part of the prog_tests/mptcp.c test by running like this? If it wants to
> exercise the other mptcp networking specific code like this, a separate
> mptcp test is needed outside of test_progs and it won't be run in the bpf
> CI.
>
> If you agree, can you please avoid introducing unnecessary randomness to the
> test_progs where bpf CI and most users don't run in this way?
Thanks Martin. Sure, I agree. Let's drop this patch.
>
> Also, please don't resend the patches too fast until the discussion is
> concluded. Please give reasonable time for others to reply.
Sure. Please give me a clear reminder next time that it's time to resend
a new version of the patches.
>
> I have a high level question. In LPC 2022
> (https://lpc.events/event/16/contributions/1354/), I recall there was idea
> in using bpf to make other mptcp decision/policy. Any thought and progress
> on this? This set which only uses bpf to change the protocol feels like an
> incomplete solution.
We are implementing MPTCP packet scheduler using BPF. Patches aren't
sent to BPF mail list yet, only temporarily on our mptcp repo[1].
Here are the patches:
selftests/bpf: Add bpf_burst test
selftests/bpf: Add bpf_burst scheduler
bpf: Export more bpf_burst related functions
selftests/bpf: Add bpf_red test
selftests/bpf: Add bpf_red scheduler
selftests/bpf: Add bpf_rr test
selftests/bpf: Add bpf_rr scheduler
selftests/bpf: Add bpf_bkup test
selftests/bpf: Add bpf_bkup scheduler
selftests/bpf: Add bpf_first test
selftests/bpf: Add bpf_first scheduler
selftests/bpf: Add bpf scheduler test
selftests/bpf: add two mptcp netns helpers
selftests/bpf: use random netns name for mptcp
selftests/bpf: Add mptcp sched structs
bpf: Add bpf_mptcp_sched_kfunc_set
bpf: Add bpf_mptcp_sched_ops
If you could take a look at these patches in advance, I would greatly
appreciate it. Any feedback is welcome.
[1]
https://github.com/multipath-tcp/mptcp_net-next.git
-Geliang
>
More information about the Linux-security-module-archive
mailing list