From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by mail.toke.dk (Postfix) with ESMTPS id 0EC839F75E1 for ; Wed, 22 Mar 2023 20:17:17 +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=IwEJFjUW Received: by mail-ed1-x52b.google.com with SMTP id cn12so31598250edb.4 for ; Wed, 22 Mar 2023 12:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679512637; 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=zq7Jl3TGbJwfMRCJgFwbgsM8JVMZ+vr7U3sGfe6jsB8=; b=IwEJFjUWISTejU0FVnsTrdJHJe6HwK372fdhRbbSA9UYXwB1Bgz77aw/8yVgn2DQ5A F6rXGGxKi86YjpcmMYtnebKufUdSIaIVUyZnxArAh6CHPOADa+yUlffw++XpSAxd4E9E GVFlY677GTCphhkdyh+uvKjffRznl21AJRM66o5tJprFyzO97+F2/V//Cxd6laqEM7+k cFEK/GUJiyE56D6rZXx5wU9FDGyfN4S2mYri3eGl+FIH/Zk7g6J+bu7IyiEQ+NhFNqpY TuKUzhtcY6Rbq7f2ym1cuHMu9A2WrMOyAT767LCavF7x9ryAAWlWvPJrF9pwlyAmwrHz 0ekQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679512637; 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=zq7Jl3TGbJwfMRCJgFwbgsM8JVMZ+vr7U3sGfe6jsB8=; b=qy+4GYbJWrYJFl+kJtgPjkPsGwywQuK4eHAC0QMOAygJzbt45yBVwuXaulh9xmv975 V/Kb11eHDsnksNg6Mkoj+13XYxKb3C8dH3IQwbs50e4A3qxIo3pixJPPbtN5/xK3Wa80 xXVw+fnQt7gPn4ibKC/cenXyX/+Ju+Q1DL5307ilNPNnuFHv8g0wmSqW/EosBlH0UYsT 7dmI7G9ZI9O6OHHC1WFnNGu6Yy164EPZsHIjqfW5p24/uQVTvGlr9SCgP+2BURQE0Zd1 pwnAAvOIQAcsaiBPOgUmIfECyTvMqJ2ofCQpPaZjZDL7MhfOL5CncrCfXzvgzHhphSc2 ChMw== X-Gm-Message-State: AO0yUKURfT83vJtOO0sp9ymxpYCYFDr+f4AajBIVBwfKCLlFhDm4G+TD 6toMoF8gwq3Zyw5nqwZX89rWWpMCsWrBME6OXoQ= X-Google-Smtp-Source: AK7set9552GdKOTmZ+tiPEVlGLee/ERxdsxUe3D7HddBqrBIhldF7UjpKsvlmjxDOFDXG2JkBtFdTg1eCUR1gkUJ0ys= X-Received: by 2002:a50:9995:0:b0:4fa:3c0b:74b with SMTP id m21-20020a509995000000b004fa3c0b074bmr4126749edb.3.1679512636925; Wed, 22 Mar 2023 12:17:16 -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: From: Alexei Starovoitov Date: Wed, 22 Mar 2023 12:17:05 -0700 Message-ID: To: Stanislav Fomichev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: BBWCMENUIBBCWOURZO7FQCNQMAPSVSNJ X-Message-ID-Hash: BBWCMENUIBBCWOURZO7FQCNQMAPSVSNJ 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: Jesper Dangaard Brouer , 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 12:00=E2=80=AFPM Stanislav Fomichev wrote: > > On Wed, Mar 22, 2023 at 9:07=E2=80=AFAM Alexei Starovoitov > wrote: > > > > 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_pro= g, > > > >> 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= /tools/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 no= t avail signal */ > > > >> } > > > >> > > > >> - if (!bpf_xdp_metadata_rx_hash(ctx, &meta->rx_hash)) > > > >> - bpf_printk("populated rx_hash with %u", meta->rx_h= ash); > > > >> - 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_hash); > > > >> + } else { > > > >> + bpf_printk("rx_hash not-avail errno:%d", ret); > > > >> meta->rx_hash =3D 0; /* Used by AF_XDP as not ava= il signal */ > > > >> + } > > > >> > > > >> return bpf_redirect_map(&xsk, ctx->rx_queue_index, XDP_PA= SS); > > > >> } > > > >> diff --git a/tools/testing/selftests/bpf/xdp_hw_metadata.c b/tools= /testing/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. Func= tional 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 o= f > > > 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 ca= n > > > 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. > > But that's not for the production? xdp_hw_metadata is a small tool to > verify that the metadata being dumped is correct (during the > development). > We have a proper (less verbose) selftest in > {progs,prog_tests}/xdp_metadata.c (over veth). > This xdp_hw_metadata was supposed to be used for running it against > the real hardware, so having as much debugging at hand as possible > seems helpful? (at least it was helpful to me when playing with mlx4) The only use of bpf_printk is for debugging of bpf progs themselves. It should not be used in any tool.