From: Martin KaFai Lau <martin.lau@linux.dev>
To: Jason Xing <kerneljasonxing@gmail.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, dsahern@kernel.org,
willemdebruijn.kernel@gmail.com, willemb@google.com,
ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, horms@kernel.org,
bpf@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH bpf-next v9 12/12] selftests/bpf: add simple bpf tests in the tx path for timestamping feature
Date: Tue, 11 Feb 2025 00:05:48 -0800 [thread overview]
Message-ID: <520cad5d-e6ab-49fe-a0f2-daa522805e19@linux.dev> (raw)
In-Reply-To: <20250208103220.72294-13-kerneljasonxing@gmail.com>
On 2/8/25 2:32 AM, Jason Xing wrote:
> ---
> .../bpf/prog_tests/so_timestamping.c | 79 +++++
> .../selftests/bpf/progs/so_timestamping.c | 312 ++++++++++++++++++
A bike shedding. s/so_timestamping.c/net_timestamping.c/
> diff --git a/tools/testing/selftests/bpf/progs/so_timestamping.c b/tools/testing/selftests/bpf/progs/so_timestamping.c
> new file mode 100644
> index 000000000000..4974552cdecb
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/so_timestamping.c
> @@ -0,0 +1,312 @@
> +#include "vmlinux.h"
> +#include "bpf_tracing_net.h"
> +#include <bpf/bpf_helpers.h>
> +#include <bpf/bpf_tracing.h>
> +#include "bpf_misc.h"
> +#include "bpf_kfuncs.h"
> +#define BPF_PROG_TEST_TCP_HDR_OPTIONS
> +#include "test_tcp_hdr_options.h"
> +#include <errno.h>
> +
> +#define SK_BPF_CB_FLAGS 1009
> +#define SK_BPF_CB_TX_TIMESTAMPING 1
> +
> +int nr_active;
> +int nr_snd;
> +int nr_passive;
> +int nr_sched;
> +int nr_txsw;
> +int nr_ack;
> +
> +struct sockopt_test {
> + int opt;
> + int new;
> +};
> +
> +static const struct sockopt_test sol_socket_tests[] = {
> + { .opt = SK_BPF_CB_FLAGS, .new = SK_BPF_CB_TX_TIMESTAMPING, },
> + { .opt = 0, },
> +};
> +
> +struct loop_ctx {
> + void *ctx;
> + const struct sock *sk;
> +};
> +
> +struct sk_stg {
> + __u64 sendmsg_ns; /* record ts when sendmsg is called */
> +};
> +
> +struct sk_tskey {
> + u64 cookie;
> + u32 tskey;
> +};
> +
> +struct delay_info {
> + u64 sendmsg_ns; /* record ts when sendmsg is called */
> + u32 sched_delay; /* SCHED_OPT_CB - sendmsg_ns */
> + u32 sw_snd_delay; /* SW_OPT_CB - SCHED_OPT_CB */
> + u32 ack_delay; /* ACK_OPT_CB - SW_OPT_CB */
> +};
> +
> +struct {
> + __uint(type, BPF_MAP_TYPE_SK_STORAGE);
> + __uint(map_flags, BPF_F_NO_PREALLOC);
> + __type(key, int);
> + __type(value, struct sk_stg);
> +} sk_stg_map SEC(".maps");
> +
> +struct {
> + __uint(type, BPF_MAP_TYPE_HASH);
> + __type(key, struct sk_tskey);
> + __type(value, struct delay_info);
> + __uint(max_entries, 1024);
> +} time_map SEC(".maps");
> +
> +static u64 delay_tolerance_nsec = 10000000000; /* 10 second as an example */
> +
> +extern int bpf_sock_ops_enable_tx_tstamp(struct bpf_sock_ops_kern *skops) __ksym;
> +
> +static int bpf_test_sockopt_int(void *ctx, const struct sock *sk,
> + const struct sockopt_test *t,
> + int level)
This should be the only one that is needed even when supporting the future RX
timestamping.
TX and RX timestamping need to be tested independently. Looping it will either
enabling them together or disabling them together. It cannot test whether RX
will work by itself.
Thus, the bpf_loop won't help. Lets remove it to simplify the test.
> +{
> + int new, opt, tmp;
> +
> + opt = t->opt;
> + new = t->new;
> +
> + if (bpf_setsockopt(ctx, level, opt, &new, sizeof(new)))
> + return 1;
> +
> + if (bpf_getsockopt(ctx, level, opt, &tmp, sizeof(tmp)) ||
> + tmp != new)
> + return 1;
> +
> + return 0;
> +}
> +
> +static int bpf_test_socket_sockopt(__u32 i, struct loop_ctx *lc)
> +{
> + const struct sockopt_test *t;
> +
> + if (i >= ARRAY_SIZE(sol_socket_tests))
> + return 1;
> +
> + t = &sol_socket_tests[i];
> + if (!t->opt)
> + return 1;
> +
> + return bpf_test_sockopt_int(lc->ctx, lc->sk, t, SOL_SOCKET);
> +}
> +
> +static int bpf_test_sockopt(void *ctx, const struct sock *sk)
> +{
> + struct loop_ctx lc = { .ctx = ctx, .sk = sk, };
> + int n;
> +
> + n = bpf_loop(ARRAY_SIZE(sol_socket_tests), bpf_test_socket_sockopt, &lc, 0);
> + if (n != ARRAY_SIZE(sol_socket_tests))
> + return -1;
> +
> + return 0;
> +}
> +
> +static bool bpf_test_access_sockopt(void *ctx)
> +{
> + const struct sockopt_test *t;
> + int tmp, ret, i = 0;
> + int level = SOL_SOCKET;
> +
> + t = &sol_socket_tests[i];
> +
> + for (; t->opt;) {
It really does not need a loop here. It only needs to test "one" optname to
ensure it is -EOPNOTSUPP.
> + ret = bpf_setsockopt(ctx, level, t->opt, (void *)&t->new, sizeof(t->new));
> + if (ret != -EOPNOTSUPP)
> + return true;
> +
> + ret = bpf_getsockopt(ctx, level, t->opt, &tmp, sizeof(tmp));
> + if (ret != -EOPNOTSUPP)
> + return true;
> +
> + if (++i >= ARRAY_SIZE(sol_socket_tests))
> + break;
> + }
> +
> + return false;
> +}
> +
> +/* Adding a simple test to see if we can get an expected value */
> +static bool bpf_test_access_load_hdr_opt(struct bpf_sock_ops *skops)
> +{
> + struct tcp_opt reg_opt;
Just noticed this one. Use a plain u8 array. Then no need to include the
"test_tcp_hdr_options.h" from an unrelated test.
> + int load_flags = 0;
> + int ret;
> +
> + reg_opt.kind = TCPOPT_EXP;
The kind could be any integer, e.g. 2.
> + reg_opt.len = 0;
> + reg_opt.data32 = 0;
> + ret = bpf_load_hdr_opt(skops, ®_opt, sizeof(reg_opt), load_flags);
> + if (ret != -EOPNOTSUPP)
> + return true;
> +
> + return false;
> +}
next prev parent reply other threads:[~2025-02-11 8:06 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-08 10:32 [PATCH bpf-next v9 00/12] net-timestamp: bpf extension to equip applications transparently Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 01/12] bpf: add support for bpf_setsockopt() Jason Xing
2025-02-11 1:02 ` Martin KaFai Lau
2025-02-11 2:24 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 02/12] bpf: prepare for timestamping callbacks use Jason Xing
2025-02-11 1:31 ` Martin KaFai Lau
2025-02-11 2:25 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 03/12] bpf: stop unsafely accessing TCP fields in bpf callbacks Jason Xing
2025-02-11 6:34 ` Martin KaFai Lau
2025-02-11 8:08 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 04/12] bpf: stop calling some sock_op BPF CALLs in new timestamping callbacks Jason Xing
2025-02-11 6:55 ` Martin KaFai Lau
2025-02-11 8:24 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 05/12] net-timestamp: prepare for isolating two modes of SO_TIMESTAMPING Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 06/12] bpf: support SCM_TSTAMP_SCHED " Jason Xing
2025-02-11 7:12 ` Martin KaFai Lau
2025-02-11 7:31 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 07/12] bpf: support sw SCM_TSTAMP_SND " Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 08/12] bpf: support hw " Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 09/12] bpf: support SCM_TSTAMP_ACK " Jason Xing
2025-02-08 17:54 ` Willem de Bruijn
2025-02-08 23:27 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 10/12] bpf: add a new callback in tcp_tx_timestamp() Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 11/12] bpf: support selective sampling for bpf timestamping Jason Xing
2025-02-11 7:41 ` Martin KaFai Lau
2025-02-11 7:48 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 12/12] selftests/bpf: add simple bpf tests in the tx path for timestamping feature Jason Xing
2025-02-11 8:05 ` Martin KaFai Lau [this message]
2025-02-11 11:37 ` Jason Xing
2025-02-10 23:37 ` [PATCH bpf-next v9 00/12] net-timestamp: bpf extension to equip applications transparently Martin KaFai Lau
2025-02-11 0:03 ` Jason Xing
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=520cad5d-e6ab-49fe-a0f2-daa522805e19@linux.dev \
--to=martin.lau@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=eddyz87@gmail.com \
--cc=edumazet@google.com \
--cc=haoluo@google.com \
--cc=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kerneljasonxing@gmail.com \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.com \
--cc=yonghong.song@linux.dev \
/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;
as well as URLs for NNTP newsgroup(s).