From: Kui-Feng Lee <sinquersw@gmail.com>
To: Kui-Feng Lee <thinker.li@gmail.com>,
bpf@vger.kernel.org, ast@kernel.org, martin.lau@linux.dev,
song@kernel.org, kernel-team@meta.com, andrii@kernel.org
Cc: kuifeng@meta.com
Subject: Re: [PATCH bpf-next 0/4] monitor network traffic for flaky test cases
Date: Sat, 13 Jul 2024 12:29:10 -0700 [thread overview]
Message-ID: <431b9131-4888-4dde-8e3f-bf5514cc8da1@gmail.com> (raw)
In-Reply-To: <20240713055552.2482367-1-thinker.li@gmail.com>
It fails on CI. Looks like we don't have tcpdump installed on CI!
On 7/12/24 22:55, Kui-Feng Lee wrote:
> Run tcpdump in the background for flaky test cases related to network
> features.
>
> We have some flaky test cases that are difficult to debug without
> knowing what the traffic looks like. With the log printed by tcpdump,
> the CI log may help developers to fix these flaky test cases.
>
> This patch set monitors a few test cases. Recently, they have been
> showing flaky behavior. If these test cases fail, they will report a
> traffic log.
>
> At the beginning and the end of a traffic log, there are additional
> traffic packets used for synchronization between the test cases and
> the tcpdump process. These packets consist of UDP packets sent to
> 127.0.0.241:4321 and ICMP unreachable messages for this
> destination. For instance, the first two and the last two packets
> serve as synchronization packets in the following log.
>
> 15:04:08.586368 lo In IP 127.0.0.1.58904 > 127.0.0.241.4321: UDP, length 5
> 15:04:08.586435 lo In IP 127.0.0.241 > 127.0.0.1: ICMP 127.0.0.241 udp port 4321 unreachable, length 41
> 15:04:08.704526 lo In IP6 ::1.52053 > ::1.45070: UDP, length 8
> 15:04:08.722785 lo In IP 127.0.0.1.51863 > 127.0.0.241.4321: UDP, length 15
> 15:04:08.722856 lo In IP 127.0.0.241 > 127.0.0.1: ICMP 127.0.0.241 udp port 4321 unreachable, length 51
>
> The IP address 127.0.0.241 is used for synchronization, so the
> loopback interface "lo" should be up in the network namespace where
> the test is being conducted. While not ideal, this should suffice for
> testing purposes.
>
> The following block is an example that monitors the network traffic of
> a test case. This test is running in the network namespace
> "testns". You can pass NULL to traffic_monitor_start() if the entire
> test, from traffic_monitor_start() to traffic_monitor_stop(), is
> running in the same namespace.
>
> struct tmonitor_ctx *tmon;
>
> ...
> tmon = traffic_monitor_start("testns");
> ASSERT_TRUE(tmon, "traffic_monitor_start");
>
> ... test ...
>
> /* Report the traffic log only if there is one or more errors. */
> if (env.subtest_state->error_cnt)
> traffic_monitor_report(tmon);
> traffic_monitor_stop(tmon);
>
> traffic_monitor_start() may fail, but we just ignore it since the
> failure doesn't affect the following test. This tracking feature
> takes another 60ms for each test with qemu on my test environment.
>
> Kui-Feng Lee (4):
> selftests/bpf: Add traffic monitor functions.
> selftests/bpf: Monitor traffic for tc_redirect/tc_redirect_dtime.
> selftests/bpf: Monitor traffic for sockmap_listen.
> selftests/bpf: Monitor traffic for select_reuseport.
>
> tools/testing/selftests/bpf/network_helpers.c | 244 ++++++++++++++++++
> tools/testing/selftests/bpf/network_helpers.h | 5 +
> .../bpf/prog_tests/select_reuseport.c | 9 +
> .../selftests/bpf/prog_tests/sockmap_listen.c | 10 +
> .../selftests/bpf/prog_tests/tc_redirect.c | 7 +
> 5 files changed, 275 insertions(+)
>
next prev parent reply other threads:[~2024-07-13 19:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-13 5:55 [PATCH bpf-next 0/4] monitor network traffic for flaky test cases Kui-Feng Lee
2024-07-13 5:55 ` [PATCH bpf-next 1/4] selftests/bpf: Add traffic monitor functions Kui-Feng Lee
2024-07-14 0:18 ` Kui-Feng Lee
2024-07-14 15:27 ` kernel test robot
2024-07-13 5:55 ` [PATCH bpf-next 2/4] selftests/bpf: Monitor traffic for tc_redirect/tc_redirect_dtime Kui-Feng Lee
2024-07-13 5:55 ` [PATCH bpf-next 3/4] selftests/bpf: Monitor traffic for sockmap_listen Kui-Feng Lee
2024-07-13 5:55 ` [PATCH bpf-next 4/4] selftests/bpf: Monitor traffic for select_reuseport Kui-Feng Lee
2024-07-13 19:29 ` Kui-Feng Lee [this message]
2024-07-15 21:33 ` [PATCH bpf-next 0/4] monitor network traffic for flaky test cases Stanislav Fomichev
2024-07-15 22:07 ` Kui-Feng Lee
2024-07-15 23:56 ` Martin KaFai Lau
2024-07-16 0:57 ` Kui-Feng Lee
2024-07-16 3:25 ` Stanislav Fomichev
2024-07-16 6:46 ` 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=431b9131-4888-4dde-8e3f-bf5514cc8da1@gmail.com \
--to=sinquersw@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=kernel-team@meta.com \
--cc=kuifeng@meta.com \
--cc=martin.lau@linux.dev \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox