Date: Fri, 11 Aug 2023 17:29:15 +0800
From: Geliang Tang <geliang.tang@...e.com>
To: Martin KaFai Lau <martin.lau@...ux.dev>
Cc: Alexei Starovoitov <ast@...nel.org>,
	Daniel Borkmann <daniel@...earbox.net>,
	Andrii Nakryiko <andrii@...nel.org>,
	Martin KaFai Lau <martin.lau@...ux.dev>, Song Liu <song@...nel.org>,
	Yonghong Song <yhs@...com>,
	John Fastabend <john.fastabend@...il.com>,
	KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...gle.com>,
	Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
	Florent Revest <revest@...omium.org>,
	Brendan Jackman <jackmanb@...omium.org>,
	Matthieu Baerts <matthieu.baerts@...sares.net>,
	Mat Martineau <martineau@...nel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	John Johansen <john.johansen@...onical.com>,
	Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Stephen Smalley <stephen.smalley.work@...il.com>,
	Eric Paris <eparis@...isplace.org>, Mykola Lysenko <mykolal@...com>,
	Shuah Khan <shuah@...nel.org>, Simon Horman <horms@...nel.org>,
	bpf@...r.kernel.org, netdev@...r.kernel.org, mptcp@...ts.linux.dev,
	apparmor@...ts.ubuntu.com, linux-security-module@...r.kernel.org,
	selinux@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH bpf-next v11 2/5] selftests/bpf: Use random netns name
 for mptcp

On Thu, Aug 10, 2023 at 10:53:38PM -0700, Martin KaFai Lau wrote:
> On 8/9/23 1:19 AM, Geliang Tang wrote:
> > 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.
> 
> Thanks you.
> 
> > > 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
> 
> Thanks for sharing. I did not go into the details. iiuc, the scheduler is
> specific to a namespace. Do you see if it is useful to have more finer
> control like depending on what IP address it is connected to? BPF policy is
> usually found more useful to have finer policy control than global or
> per-netns.
> 
> The same question goes for the fmod_ret here in this patch. The
> progs/mptcpify.c selftest is as good as upgrading all TCP connections. Is it
> your only use case and no need for finer selection?

This per-netns control is just the first step. We do need finer selection. The
most ideal mode is to select one app to upgrade it's TCP connections only. So
per-cgroup control is much better than per-netns. But we haven't found a good
per-cgroup solution yet.

Thanks,
-Geliang

> 

Powered by blists - more mailing lists