From: Martin KaFai Lau <martin.lau@linux.dev>
To: Stanislav Fomichev <sdf@google.com>
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
song@kernel.org, yhs@fb.com, john.fastabend@gmail.com,
kpsingh@kernel.org, haoluo@google.com, jolsa@kernel.org,
Jakub Kicinski <kuba@kernel.org>,
Willem de Bruijn <willemb@google.com>,
Jesper Dangaard Brouer <brouer@redhat.com>,
Anatoly Burakov <anatoly.burakov@intel.com>,
Alexander Lobakin <alexandr.lobakin@intel.com>,
Magnus Karlsson <magnus.karlsson@gmail.com>,
Maryam Tahhan <mtahhan@redhat.com>,
xdp-hints@xdp-project.net, netdev@vger.kernel.org,
bpf@vger.kernel.org
Subject: Re: [RFC bpf-next 5/5] selftests/bpf: Test rx_timestamp metadata in xskxceiver
Date: Thu, 27 Oct 2022 23:22:51 -0700 [thread overview]
Message-ID: <31f3aa18-d368-9738-8bb5-857cd5f2c5bf@linux.dev> (raw)
In-Reply-To: <20221027200019.4106375-6-sdf@google.com>
On 10/27/22 1:00 PM, Stanislav Fomichev wrote:
> Example on how the metadata is prepared from the BPF context
> and consumed by AF_XDP:
>
> - bpf_xdp_metadata_have_rx_timestamp to test whether it's supported;
> if not, I'm assuming verifier will remove this "if (0)" branch
> - bpf_xdp_metadata_rx_timestamp returns a _copy_ of metadata;
> the program has to bpf_xdp_adjust_meta+memcpy it;
> maybe returning a pointer is better?
> - af_xdp consumer grabs it from data-<expected_metadata_offset> and
> makes sure timestamp is not empty
> - when loading the program, we pass BPF_F_XDP_HAS_METADATA+prog_ifindex
>
> Cc: Martin KaFai Lau <martin.lau@linux.dev>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Willem de Bruijn <willemb@google.com>
> Cc: Jesper Dangaard Brouer <brouer@redhat.com>
> Cc: Anatoly Burakov <anatoly.burakov@intel.com>
> Cc: Alexander Lobakin <alexandr.lobakin@intel.com>
> Cc: Magnus Karlsson <magnus.karlsson@gmail.com>
> Cc: Maryam Tahhan <mtahhan@redhat.com>
> Cc: xdp-hints@xdp-project.net
> Cc: netdev@vger.kernel.org
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
> ---
> .../testing/selftests/bpf/progs/xskxceiver.c | 22 ++++++++++++++++++
> tools/testing/selftests/bpf/xskxceiver.c | 23 ++++++++++++++++++-
> 2 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/bpf/progs/xskxceiver.c b/tools/testing/selftests/bpf/progs/xskxceiver.c
> index b135daddad3a..83c879aa3581 100644
> --- a/tools/testing/selftests/bpf/progs/xskxceiver.c
> +++ b/tools/testing/selftests/bpf/progs/xskxceiver.c
> @@ -12,9 +12,31 @@ struct {
> __type(value, __u32);
> } xsk SEC(".maps");
>
> +extern int bpf_xdp_metadata_have_rx_timestamp(struct xdp_md *ctx) __ksym;
> +extern __u32 bpf_xdp_metadata_rx_timestamp(struct xdp_md *ctx) __ksym;
> +
> SEC("xdp")
> int rx(struct xdp_md *ctx)
> {
> + void *data, *data_meta;
> + __u32 rx_timestamp;
> + int ret;
> +
> + if (bpf_xdp_metadata_have_rx_timestamp(ctx)) {
> + ret = bpf_xdp_adjust_meta(ctx, -(int)sizeof(__u32));
> + if (ret != 0)
> + return XDP_DROP;
> +
> + data = (void *)(long)ctx->data;
> + data_meta = (void *)(long)ctx->data_meta;
> +
> + if (data_meta + sizeof(__u32) > data)
> + return XDP_DROP;
> +
> + rx_timestamp = bpf_xdp_metadata_rx_timestamp(ctx);
> + __builtin_memcpy(data_meta, &rx_timestamp, sizeof(__u32));
> + }
Thanks for the patches. I took a quick look at patch 1 and 2 but haven't had a
chance to look at the implementation details (eg. KF_UNROLL...etc), yet.
Overall (with the example here) looks promising. There is a lot of flexibility
on whether the xdp prog needs any hint at all, which hint it needs, and how to
store it.
> +
> return bpf_redirect_map(&xsk, ctx->rx_queue_index, XDP_PASS);
> }
>
> diff --git a/tools/testing/selftests/bpf/xskxceiver.c b/tools/testing/selftests/bpf/xskxceiver.c
> index 066bd691db13..ce82c89a432e 100644
> --- a/tools/testing/selftests/bpf/xskxceiver.c
> +++ b/tools/testing/selftests/bpf/xskxceiver.c
> @@ -871,7 +871,9 @@ static bool is_offset_correct(struct xsk_umem_info *umem, struct pkt_stream *pkt
> static bool is_pkt_valid(struct pkt *pkt, void *buffer, u64 addr, u32 len)
> {
> void *data = xsk_umem__get_data(buffer, addr);
> + void *data_meta = data - sizeof(__u32);
> struct iphdr *iphdr = (struct iphdr *)(data + sizeof(struct ethhdr));
> + __u32 rx_timestamp = 0;
>
> if (!pkt) {
> ksft_print_msg("[%s] too many packets received\n", __func__);
> @@ -907,6 +909,13 @@ static bool is_pkt_valid(struct pkt *pkt, void *buffer, u64 addr, u32 len)
> return false;
> }
>
> + memcpy(&rx_timestamp, data_meta, sizeof(rx_timestamp));
> + if (rx_timestamp == 0) {
> + ksft_print_msg("Invalid metadata received: ");
> + ksft_print_msg("got %08x, expected != 0\n", rx_timestamp);
> + return false;
> + }
> +
> return true;
> }
>
next prev parent reply other threads:[~2022-10-28 6:23 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-27 20:00 [RFC bpf-next 0/5] xdp: hints via kfuncs Stanislav Fomichev
2022-10-27 20:00 ` [RFC bpf-next 1/5] bpf: Support inlined/unrolled kfuncs for xdp metadata Stanislav Fomichev
2022-10-27 22:10 ` kernel test robot
2022-10-28 2:23 ` kernel test robot
2022-10-28 3:13 ` kernel test robot
2022-10-27 20:00 ` [RFC bpf-next 2/5] veth: Support rx timestamp metadata for xdp Stanislav Fomichev
2022-10-28 8:40 ` Jesper Dangaard Brouer
2022-10-28 18:46 ` Stanislav Fomichev
2022-10-27 20:00 ` [RFC bpf-next 3/5] libbpf: Pass prog_ifindex via bpf_object_open_opts Stanislav Fomichev
2022-10-27 20:05 ` Andrii Nakryiko
2022-10-27 20:10 ` Stanislav Fomichev
2022-10-27 20:00 ` [RFC bpf-next 4/5] selftests/bpf: Convert xskxceiver to use custom program Stanislav Fomichev
2022-10-27 20:00 ` [RFC bpf-next 5/5] selftests/bpf: Test rx_timestamp metadata in xskxceiver Stanislav Fomichev
2022-10-28 6:22 ` Martin KaFai Lau [this message]
2022-10-28 10:37 ` Jesper Dangaard Brouer
2022-10-28 18:46 ` Stanislav Fomichev
2022-10-31 14:20 ` Alexander Lobakin
2022-10-31 14:29 ` Alexander Lobakin
2022-10-31 17:00 ` Stanislav Fomichev
2022-11-01 13:18 ` Jesper Dangaard Brouer
2022-11-01 20:12 ` Stanislav Fomichev
2022-11-01 22:23 ` [xdp-hints] " Toke Høiland-Jørgensen
2022-10-28 15:58 ` [RFC bpf-next 0/5] xdp: hints via kfuncs John Fastabend
2022-10-28 18:04 ` Jakub Kicinski
2022-10-28 18:46 ` Stanislav Fomichev
2022-10-28 23:16 ` John Fastabend
2022-10-29 1:14 ` Jakub Kicinski
2022-10-31 14:10 ` [xdp-hints] " Bezdeka, Florian
2022-10-31 15:28 ` Toke Høiland-Jørgensen
2022-10-31 17:00 ` Stanislav Fomichev
2022-10-31 22:57 ` Martin KaFai Lau
2022-11-01 1:59 ` Stanislav Fomichev
2022-11-01 12:52 ` Toke Høiland-Jørgensen
2022-11-01 13:43 ` David Ahern
2022-11-01 14:20 ` Toke Høiland-Jørgensen
2022-11-01 17:05 ` Martin KaFai Lau
2022-11-01 20:12 ` Stanislav Fomichev
2022-11-02 14:06 ` Jesper Dangaard Brouer
2022-11-02 22:01 ` Toke Høiland-Jørgensen
2022-11-02 23:10 ` Stanislav Fomichev
2022-11-03 0:09 ` Toke Høiland-Jørgensen
2022-11-03 12:01 ` Jesper Dangaard Brouer
2022-11-03 12:48 ` Toke Høiland-Jørgensen
2022-11-03 15:25 ` Jesper Dangaard Brouer
2022-10-31 19:36 ` Yonghong Song
2022-10-31 22:09 ` Stanislav Fomichev
2022-10-31 22:38 ` Yonghong Song
2022-10-31 22:55 ` Stanislav Fomichev
2022-11-01 14:23 ` Jesper Dangaard Brouer
2022-11-01 17:31 ` Martin KaFai Lau
2022-11-01 20:12 ` Stanislav Fomichev
2022-11-01 21:17 ` Martin KaFai Lau
2022-10-31 17:01 ` John Fastabend
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=31f3aa18-d368-9738-8bb5-857cd5f2c5bf@linux.dev \
--to=martin.lau@linux.dev \
--cc=alexandr.lobakin@intel.com \
--cc=anatoly.burakov@intel.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=magnus.karlsson@gmail.com \
--cc=mtahhan@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=willemb@google.com \
--cc=xdp-hints@xdp-project.net \
--cc=yhs@fb.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.