From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mail.toke.dk (Postfix) with ESMTPS id 21F9A9FD2EC for ; Wed, 12 Apr 2023 14:42:56 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Zrm6exMV DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681303375; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xPA/2DPgV7DkzsAGv07BeNJ4vzcmIchr5dPwJsagFdw=; b=Zrm6exMVT9T7/jkfBqVHUb948lah8jPXd4M5b93VwcxmLzLMxpIt/3Yg161GzB8Lc4DGpN T5bpS9BBXyzx0jYLX6FB0MCHY2ONV095DjDpscWB+Z9WQWmcCmnEWCR1T3P6+kntBD/ah2 Bb7GXhAGg0QmLdHhv78KZDKIJEQiuFU= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-427-Zz-IJwvuPi6Z5sEwkERDlA-1; Wed, 12 Apr 2023 08:42:51 -0400 X-MC-Unique: Zz-IJwvuPi6Z5sEwkERDlA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 758671C09079; Wed, 12 Apr 2023 12:42:43 +0000 (UTC) Received: from firesoul.localdomain (unknown [10.45.242.24]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2405B40BC797; Wed, 12 Apr 2023 12:42:43 +0000 (UTC) Received: from [10.1.1.1] (localhost [IPv6:::1]) by firesoul.localdomain (Postfix) with ESMTP id 38F48307372E8; Wed, 12 Apr 2023 14:42:42 +0200 (CEST) From: Jesper Dangaard Brouer To: bpf@vger.kernel.org, Stanislav Fomichev , =?utf-8?q?Toke_H=C3=B8iland-J=C3=B8rgensen?= Date: Wed, 12 Apr 2023 14:42:42 +0200 Message-ID: <168130336215.150247.1088133245386431977.stgit@firesoul> In-Reply-To: <168130333143.150247.11159481574477358816.stgit@firesoul> References: <168130333143.150247.11159481574477358816.stgit@firesoul> User-Agent: StGit/1.4 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 Message-ID-Hash: V4XMXI2TX5J7LW5ZOPKJJPWTNEYGASG6 X-Message-ID-Hash: V4XMXI2TX5J7LW5ZOPKJJPWTNEYGASG6 X-MailFrom: brouer@redhat.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 , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, martin.lau@kernel.org, ast@kernel.org, daniel@iogearbox.net, alexandr.lobakin@intel.com, larysa.zaremba@intel.com, xdp-hints@xdp-project.net, anthony.l.nguyen@intel.com, yoong.siang.song@intel.com, boon.leong.ong@intel.com, intel-wired-lan@lists.osuosl.org, pabeni@redhat.com, jesse.brandeburg@intel.com, kuba@kernel.org, edumazet@google.com, john.fastabend@gmail.com, hawk@kernel.org, davem@davemloft.net, tariqt@nvidia.com, saeedm@nvidia.com, leon@kernel.org, linux-rdma@vger.kernel.org X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] [PATCH bpf V8 1/7] selftests/bpf: xdp_hw_metadata default disable bpf_printk List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: The tool xdp_hw_metadata can be used by driver developers implementing XDP-hints kfuncs. The tool transfers the XDP-hints via metadata information to an AF_XDP userspace process. When everything works the bpf_printk calls are unncesssary. Thus, disable bpf_printk by default, but make it easy to reenable for driver developers to use when debugging their driver implementation. Next patch will add counters to track some of these cases. That will provide a hint to re-enable bpf_printk. This also converts bpf_printk "forwarding UDP:9091 to AF_XDP" into a code comment. The bpf_printk's that are important to the driver developers is when bpf_xdp_adjust_meta fails. The likely mistake from driver developers is expected to be that they didn't implement XDP metadata adjust support. Signed-off-by: Jesper Dangaard Brouer --- .../testing/selftests/bpf/progs/xdp_hw_metadata.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/bpf/progs/xdp_hw_metadata.c b/tools/testing/selftests/bpf/progs/xdp_hw_metadata.c index 4c55b4d79d3d..b0104763405a 100644 --- a/tools/testing/selftests/bpf/progs/xdp_hw_metadata.c +++ b/tools/testing/selftests/bpf/progs/xdp_hw_metadata.c @@ -5,6 +5,19 @@ #include #include +/* Per default below bpf_printk() calls are disabled. Can be + * reenabled manually for convenience by XDP-hints driver developer, + * when troubleshooting the drivers kfuncs implementation details. + * + * Remember BPF-prog bpf_printk info output can be access via: + * /sys/kernel/debug/tracing/trace_pipe + */ +//#define DEBUG 1 +#ifndef DEBUG +#undef bpf_printk +#define bpf_printk(fmt, ...) ({}) +#endif + struct { __uint(type, BPF_MAP_TYPE_XSKMAP); __uint(max_entries, 256); @@ -49,11 +62,10 @@ int rx(struct xdp_md *ctx) if (!udp) return XDP_PASS; + /* Forwarding UDP:9091 to AF_XDP */ if (udp->dest != bpf_htons(9091)) return XDP_PASS; - bpf_printk("forwarding UDP:9091 to AF_XDP"); - ret = bpf_xdp_adjust_meta(ctx, -(int)sizeof(struct xdp_meta)); if (ret != 0) { bpf_printk("bpf_xdp_adjust_meta returned %d", ret);