From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by mail.toke.dk (Postfix) with ESMTPS id 021B79E5E95 for ; Tue, 31 Jan 2023 20:02:11 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20210112 header.b=fdvPWwMK Received: by mail-pf1-x433.google.com with SMTP id w20so1984349pfn.4 for ; Tue, 31 Jan 2023 11:02:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=iSlbitpVXsAiKWUKOS8hJcan2Um7j/V24BYCeu085pQ=; b=fdvPWwMKP2aLjGaQ8NVXQsaovrWw5foZPtc/QP3r0wy9C/u06t1dfcKtwtMmDD5F12 FZtTLNPDw3In1StcXGAVJ/mdFvbA5qNHADV86MCamiZ2ZXKKoSnJojUGhMsTROxc8Glx h/jH0cBg1T8J/4agw+jc7V2tSXMa4jlHuI0aqLB9xLcIg/DW+447kH2fy6uA69JJj0pq 3C8evbw5mt/b6SWNqaHToBxE1pxuL5ABD9QJCyQmMeOCjaOJUt9SryikrP80SnjoHrVI 0m8djGD8QPjdeDR7Q1jOFvpKMkqm9ls/AgKR0zufuSnHKzp8/HfJ+WiARA1P+nCdBP+c 4mqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=iSlbitpVXsAiKWUKOS8hJcan2Um7j/V24BYCeu085pQ=; b=WJZniD2Ii0WeKG5noUL8KpUYBSCyo84SYb96xEOFNg+FhIlgvO1z8/s/eg38dE3oie 7bGrKD+3qERbuPTxhgxLGzn0eKLieAXOkRxP/SXFojyI8S5SWF1hYok0rBqWs2G87gUR j6gpc0epoBPBloiDY8oqUvEHLOHIYMXQuEwZfOaNX4874FFA4foKn+tNLk/vpf0bcr1P RjNTkOmMaT6Ar07hAPET2Ch1NJLjmDrqYzSIl9NrzZG4gPpbicOF63hw5+PTn4rSwGU9 xJPxYxL+wruF2DYnq73/Lkatbkt6MLRBv6fiQhJyuZFW0Lsc3mUzYVRD5tabBC79Uigq hZJw== X-Gm-Message-State: AFqh2krbBZuQ8xUEZMLhrVkl6kPt7xyC3CmTiFP9wtwz23A7oLnfeump c0rVMAF3QYsq+Jye7JY/vbV3P0M/x1Y4jUBB+6s1oA== X-Google-Smtp-Source: AMrXdXsQiX/y+zxoMR4fjq09QC3yLQ82xRlHwgrrx86+hvYct8MxPYHtPo6KhXYHINBUEQsWoCXJoGqyQKakDT8vxoI= X-Received: by 2002:a63:946:0:b0:4cf:7ba0:dd5a with SMTP id 67-20020a630946000000b004cf7ba0dd5amr6008626pgj.119.1675191728977; Tue, 31 Jan 2023 11:02:08 -0800 (PST) MIME-Version: 1.0 References: <167482734243.892262.18210955230092032606.stgit@firesoul> <87cz70krjv.fsf@toke.dk> <839c6cbb-1572-b3a8-57eb-2aa2488101dd@redhat.com> In-Reply-To: <839c6cbb-1572-b3a8-57eb-2aa2488101dd@redhat.com> From: Stanislav Fomichev Date: Tue, 31 Jan 2023 11:01:57 -0800 Message-ID: To: Jesper Dangaard Brouer Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: TST64DLFTKT62K32F76N5FVQ42UC4PHO X-Message-ID-Hash: TST64DLFTKT62K32F76N5FVQ42UC4PHO X-MailFrom: sdf@google.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: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , brouer@redhat.com, bpf@vger.kernel.org, netdev@vger.kernel.org, martin.lau@kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@fb.com, john.fastabend@gmail.com, dsahern@gmail.com, willemb@google.com, void@manifault.com, kuba@kernel.org, xdp-hints@xdp-project.net X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next RFC V1] selftests/bpf: xdp_hw_metadata clear metadata when -EOPNOTSUPP List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue, Jan 31, 2023 at 5:00 AM Jesper Dangaard Brouer wrote: > > > > On 27/01/2023 18.18, Stanislav Fomichev wrote: > > On Fri, Jan 27, 2023 at 5:58 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > >> > >> Jesper Dangaard Brouer writes: > >> > >>> The AF_XDP userspace part of xdp_hw_metadata see non-zero as a signal= of > >>> the availability of rx_timestamp and rx_hash in data_meta area. The > >>> kernel-side BPF-prog code doesn't initialize these members when kerne= l > >>> returns an error e.g. -EOPNOTSUPP. This memory area is not guarantee= d to > >>> be zeroed, and can contain garbage/previous values, which will be rea= d > >>> and interpreted by AF_XDP userspace side. > >>> > >>> Tested this on different drivers. The experiences are that for most > >>> packets they will have zeroed this data_meta area, but occasionally i= t > >>> will contain garbage data. > >>> > >>> Example of failure tested on ixgbe: > >>> poll: 1 (0) > >>> xsk_ring_cons__peek: 1 > >>> 0x18ec788: rx_desc[0]->addr=3D100000000008000 addr=3D8100 comp_addr= =3D8000 > >>> rx_hash: 3697961069 > >>> rx_timestamp: 9024981991734834796 (sec:9024981991.7348) > >>> 0x18ec788: complete idx=3D8 addr=3D8000 > >>> > >>> Converting to date: > >>> date -d @9024981991 > >>> 2255-12-28T20:26:31 CET > >>> > >>> I choose a simple fix in this patch. When kfunc fails or isn't suppor= ted > >>> assign zero to the corresponding struct meta value. > >>> > >>> It's up to the individual BPF-programmer to do something smarter e.g. > >>> that fits their use-case, like getting a software timestamp and marki= ng > >>> a flag that gives the type of timestamp. > >>> > >>> Another possibility is for the behavior of kfunc's > >>> bpf_xdp_metadata_rx_timestamp and bpf_xdp_metadata_rx_hash to require > >>> clearing return value pointer. > >> > >> I definitely think we should leave it up to the BPF programmer to reac= t > >> to failures; that's what the return code is there for, after all :) > > > > +1 > > +1 I agree. > We should keep this default functions as simple as possible, for future > "unroll" of BPF-bytecode. > > I the -EOPNOTSUPP case (default functions for drivers not implementing > kfunc), will likely be used runtime by BPF-prog to determine if the > hardware have this offload hint, but it comes with the overhead of a > function pointer call. > > I hope we can somehow BPF-bytecode "unroll" these (default functions) at > BPF-load time, to remove this overhead, and perhaps even let BPF > bytecode do const propagation and code elimination? > > > > Maybe we can unconditionally memset(meta, sizeof(*meta), 0) in > > tools/testing/selftests/bpf/progs/xdp_hw_metadata.c? > > Since it's not a performance tool, it should be ok functionality-wise. > > I know this isn't a performance test, but IMHO always memsetting > metadata area is a misleading example. We know from experience that > developer simply copy-paste code examples, even quick-n-dirty testing > example code. > > The specific issue in this example can lead to hard-to-find bugs, as my > testing shows it is only occasionally that data_meta area contains > garbage. We could do a memset, but it deserves a large code comment, why > this is needed, so people copy-pasting understand. I choose current > approach to keep code close to code people will copy-paste. SG, I don't think it matters, but agreed that having this stated explicitly could help with a blind copy-paste :-) Then maybe repost with the TODO's removed from the kfucs? We seem to agree that it's the user's job to manage the final buffer.. > --Jesper >