From: Martin KaFai Lau <martin.lau@linux.dev>
To: Kui-Feng Lee <sinquersw@gmail.com>, Kui-Feng Lee <thinker.li@gmail.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, song@kernel.org,
kernel-team@meta.com, andrii@kernel.org, sdf@fomichev.me,
kuifeng@meta.com
Subject: Re: [PATCH bpf-next v2 1/4] selftests/bpf: Add traffic monitor functions.
Date: Thu, 25 Jul 2024 17:23:51 -0700 [thread overview]
Message-ID: <7003dd9a-3458-46ea-b9b8-6025241b6833@linux.dev> (raw)
In-Reply-To: <c80120a6-6991-4de9-a705-5533282e3e67@gmail.com>
On 7/25/24 3:47 PM, Kui-Feng Lee wrote:
>>> +/* Start to monitor the network traffic in the given network namespace.
>>> + *
>>> + * netns: the name of the network namespace to monitor. If NULL, the
>>> + * current network namespace is monitored.
>>> + *
>>> + * This function will start a thread to capture packets going through NICs
>>> + * in the give network namespace.
>>> + */
>>> +struct tmonitor_ctx *traffic_monitor_start(const char *netns)
>>
>> There is opportunity to make the traffic monitoring easier for tests that
>> create its own netns which I hope most of the networking tests fall into this
>> bucket now. Especially for tests that create multiple netns such that the test
>> does not have to start/stop for each individual netns.
>>
>> May be adding an API like "struct nstoken *netns_new(const char *netns_name)".
>> The netns_new() will create the netns and (optionally) start the monitoring
>> thread also. It will need another "void netns_free(struct nstoken *nstoken)"
>> to stop the thread and remove the netns. The "struct tmonitor_ctx" probably
>> makes sense to be embedded into "struct nstoken" if we go with this new API.
>
> Agree! But, I think we need another type rather than to reuse "struct
> netns". People may accidentally call close_netns() on the nstoken
> returned by this function.
ah. Good point. close_netns() does free the nstoken also...
yep. probably make sense to have another type for netns create/destroy which
start/stop the monitoring automatically based on the on/off in the libpcap.list.
>
>>
>> This will need some changes to the tests creating netns but it probably should
>> be obvious change considering most test do "ip netns add..." and then
>> open_netns(). It can start with the flaky test at hand first like tc_redirect.
>>
>> May be a little more changes for the test using "unshare(CLONE_NEWNET)" but
>> should not be too bad either. This can be done only when we need to turn on
>> libpcap to debug that test.
>>
>> Also, when the test is flaky, make it easier for people not familiar with the
>> codes of the networking test to turn on traffic monitoring without changing
>> the test code. May be in a libpcap.list file (in parallel to the existing
>> DENYLIST)?
>>
>> For the tests without having its own netns, they can either move to netns
>> (which I think it is a good thing to do) or use the
>> traffic_monitor_start/stop() manually by changing the testing code,
>> or a better way is to ask test_progs do it for the host netns (init_netns)
>> automatically for all tests in the libpcap.list.
>
> Agree! I will start move some tests to netns, and use libpcap.list to
> enable them.
The tc_redirect test should be in netns already. It seems the select_reuseport
and the sockmap_listen test, that this patchset is touching, are not in netns. I
hope the netns migration changes should be obvious for them. Other than those
two flaky tests, I would separate other netns moving work to another effort.
next prev parent reply other threads:[~2024-07-26 0:24 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-23 18:24 [PATCH bpf-next v2 0/4] monitor network traffic for flaky test cases Kui-Feng Lee
2024-07-23 18:24 ` [PATCH bpf-next v2 1/4] selftests/bpf: Add traffic monitor functions Kui-Feng Lee
2024-07-23 22:03 ` Kui-Feng Lee
2024-07-24 15:22 ` Stanislav Fomichev
2024-07-24 15:46 ` Kui-Feng Lee
2024-07-24 19:08 ` Martin KaFai Lau
2024-07-25 1:44 ` Martin KaFai Lau
2024-07-25 22:47 ` Kui-Feng Lee
2024-07-26 0:23 ` Martin KaFai Lau [this message]
2024-07-23 18:24 ` [PATCH bpf-next v2 2/4] selftests/bpf: Monitor traffic for tc_redirect/tc_redirect_dtime Kui-Feng Lee
2024-07-24 8:36 ` Geliang Tang
2024-07-24 16:24 ` Kui-Feng Lee
2024-07-24 15:26 ` Stanislav Fomichev
2024-07-24 18:04 ` Kui-Feng Lee
2024-07-24 22:13 ` Stanislav Fomichev
2024-07-23 18:24 ` [PATCH bpf-next v2 3/4] selftests/bpf: Monitor traffic for sockmap_listen Kui-Feng Lee
2024-07-24 9:32 ` Geliang Tang
2024-07-24 16:24 ` Kui-Feng Lee
2024-07-24 18:11 ` Andrii Nakryiko
2024-07-23 18:24 ` [PATCH bpf-next v2 4/4] selftests/bpf: Monitor traffic for select_reuseport Kui-Feng Lee
2024-07-24 9:33 ` Geliang Tang
2024-07-23 22:01 ` [PATCH bpf-next v2 0/4] monitor network traffic for flaky test cases Kui-Feng Lee
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=7003dd9a-3458-46ea-b9b8-6025241b6833@linux.dev \
--to=martin.lau@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=kernel-team@meta.com \
--cc=kuifeng@meta.com \
--cc=sdf@fomichev.me \
--cc=sinquersw@gmail.com \
--cc=song@kernel.org \
--cc=thinker.li@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.