From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by mail.toke.dk (Postfix) with ESMTPS id 132E19F74D5 for ; Wed, 22 Mar 2023 17:07:53 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=KwKrLt++ Received: by mail-ed1-x52a.google.com with SMTP id ek18so75079329edb.6 for ; Wed, 22 Mar 2023 09:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679501273; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mOzog1rcJBIJ0IWpoVcxs5p5wXubMGjNYuLplz2RPz0=; b=KwKrLt++JgVHYPV+zzH2vsrhxtmgPAAlhxhmkHaW5Tn1Uv3QfKENWI9nJhy7yvpxlK /lftz09YJtHFS1Oim2MNM2FSKBdNhIeP1Tuz6Tvxn6XgLNhixDP3VM7Zdc9xkrUHQy7C VMc0wxBq0ghfmRfS1WRhg+boL8oug5wZzjhS3yLiSxkglMV5ZKWPWp3eMfI8Fq0dSSbL OA/ey/3LS7BhlvFaMUCQOqORHj7aOrCJqsgFP4wgCuQd+duVn2oCa4eGxPH7LyqAIDFd HyDXN8k1c55LycGNCDmyMDTNFn+bwi9f0ok4XeLJrAh3GtQC7nFbKP8H96/S7vfjKn4b 6ENg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679501273; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mOzog1rcJBIJ0IWpoVcxs5p5wXubMGjNYuLplz2RPz0=; b=Uri4Xjku4skWA7WQ4JV8uvWiABDvvB2MuYmKHNZlPcA3x3mP+5VR0qCwJTd8l2fsYM 0m2ZW+jBTcS1Zrzd9Gt9rwCeFxMoFYA27f/QsS4Xe4ofml1Y2BGHcn0un4yP8KVhdjWR m8XUN2QlAh65i5PCwGp6Y8/cekaiqABTZYqsudPNY03b4NUYozWo30iZ9U/VMe9+hwsf rbzWR2uJNOfpOrRhV1TWV8MQmjSPVLAZ/hBU2p009OepYzVhjghnubTQWKrtgvUswANN a6nOhI4tKCXvBl0CrHCvjbC/RgIFa2EOncdiKimHmNfaI0Royh/xdeEZy5me1JMt6lhB nWTA== X-Gm-Message-State: AO0yUKWj+Xm48fjynGFw+QvBfljjO+lP31UCEgTqHfhI91j9FWjoMQtz +RXtInryXXPYKChvTNqgksymUQZaL5AYqn6EnnA= X-Google-Smtp-Source: AK7set8U2axS8vjpTT71ShGMMBPNsw6nJfxB/FJqNUP5haOFL3RpVeqtsMlGUxJwfDHo3l1mRyT0yLGgeSBExss0N70= X-Received: by 2002:a17:906:2cc5:b0:931:c1a:b517 with SMTP id r5-20020a1709062cc500b009310c1ab517mr3409072ejr.3.1679501273106; Wed, 22 Mar 2023 09:07:53 -0700 (PDT) MIME-Version: 1.0 References: <167940634187.2718137.10209374282891218398.stgit@firesoul> <167940643669.2718137.4624187727245854475.stgit@firesoul> <080640fc-5835-26f1-2b20-ff079bd59182@redhat.com> In-Reply-To: <080640fc-5835-26f1-2b20-ff079bd59182@redhat.com> From: Alexei Starovoitov Date: Wed, 22 Mar 2023 09:07:41 -0700 Message-ID: To: Jesper Dangaard Brouer Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: Q5O2EAQUAAW2OBKI263MMJ2JVGHSWV7S X-Message-ID-Hash: Q5O2EAQUAAW2OBKI263MMJ2JVGHSWV7S X-MailFrom: alexei.starovoitov@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Stanislav Fomichev , Jesper Dangaard Brouer , bpf , Network Development , Martin KaFai Lau , Alexei Starovoitov , Daniel Borkmann , Alexander Lobakin , Larysa Zaremba , xdp-hints@xdp-project.net, anthony.l.nguyen@intel.com, "Song, Yoong Siang" , "Ong, Boon Leong" , intel-wired-lan , Paolo Abeni , Jesse Brandeburg , Jakub Kicinski , Eric Dumazet , John Fastabend , Jesper Dangaard Brouer , "David S. Miller" X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next V2 3/6] selftests/bpf: xdp_hw_metadata RX hash return code info List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, Mar 22, 2023 at 9:05=E2=80=AFAM Jesper Dangaard Brouer wrote: > > > > On 21/03/2023 19.47, Stanislav Fomichev wrote: > > On Tue, Mar 21, 2023 at 6:47=E2=80=AFAM Jesper Dangaard Brouer > > wrote: > >> > >> When driver developers add XDP-hints kfuncs for RX hash it is > >> practical to print the return code in bpf_printk trace pipe log. > >> > >> Print hash value as a hex value, both AF_XDP userspace and bpf_prog, > >> as this makes it easier to spot poor quality hashes. > >> > >> Signed-off-by: Jesper Dangaard Brouer > >> --- > >> .../testing/selftests/bpf/progs/xdp_hw_metadata.c | 9 ++++++--- > >> tools/testing/selftests/bpf/xdp_hw_metadata.c | 5 ++++- > >> 2 files changed, 10 insertions(+), 4 deletions(-) > >> > >> diff --git a/tools/testing/selftests/bpf/progs/xdp_hw_metadata.c b/too= ls/testing/selftests/bpf/progs/xdp_hw_metadata.c > >> index 40c17adbf483..ce07010e4d48 100644 > >> --- a/tools/testing/selftests/bpf/progs/xdp_hw_metadata.c > >> +++ b/tools/testing/selftests/bpf/progs/xdp_hw_metadata.c > >> @@ -77,10 +77,13 @@ int rx(struct xdp_md *ctx) > >> meta->rx_timestamp =3D 0; /* Used by AF_XDP as not av= ail signal */ > >> } > >> > >> - if (!bpf_xdp_metadata_rx_hash(ctx, &meta->rx_hash)) > >> - bpf_printk("populated rx_hash with %u", meta->rx_hash)= ; > >> - else > >> + ret =3D bpf_xdp_metadata_rx_hash(ctx, &meta->rx_hash); > >> + if (ret >=3D 0) { > >> + bpf_printk("populated rx_hash with 0x%08X", meta->rx_h= ash); > >> + } else { > >> + bpf_printk("rx_hash not-avail errno:%d", ret); > >> meta->rx_hash =3D 0; /* Used by AF_XDP as not avail s= ignal */ > >> + } > >> > >> return bpf_redirect_map(&xsk, ctx->rx_queue_index, XDP_PASS); > >> } > >> diff --git a/tools/testing/selftests/bpf/xdp_hw_metadata.c b/tools/tes= ting/selftests/bpf/xdp_hw_metadata.c > >> index 400bfe19abfe..f3ec07ccdc95 100644 > >> --- a/tools/testing/selftests/bpf/xdp_hw_metadata.c > >> +++ b/tools/testing/selftests/bpf/xdp_hw_metadata.c > >> @@ -3,6 +3,9 @@ > >> /* Reference program for verifying XDP metadata on real HW. Function= al test > >> * only, doesn't test the performance. > >> * > >> + * BPF-prog bpf_printk info outout can be access via > >> + * /sys/kernel/debug/tracing/trace_pipe > > > > s/outout/output/ > > > > Fixed in V3 > > > But let's maybe drop it? If you want to make it more usable, let's > > have a separate patch to enable tracing and periodically dump it to > > the console instead (as previously discussed). > > Cat'ing /sys/kernel/debug/tracing/trace_pipe work for me regardless of > setting in > /sys/kernel/debug/tracing/events/bpf_trace/bpf_trace_printk/enable > > We likely need a followup patch that adds a BPF config switch that can > disable bpf_printk calls, because this adds overhead and thus affects > the timestamps. No. This is by design. Do not use bpf_printk* in production.