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 >
