From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by mail.toke.dk (Postfix) with ESMTPS id D02F19E5245 for ; Fri, 27 Jan 2023 18:18:33 +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=PjAdEhry Received: by mail-pj1-x1035.google.com with SMTP id x2-20020a17090a46c200b002295ca9855aso9261811pjg.2 for ; Fri, 27 Jan 2023 09:18:33 -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=qtouv6Z6Gh5nIAaDvGdVmaZJMnuDScOHiRWBgSzL7vs=; b=PjAdEhrytMEw3NDmnzkGw1Ha9Tvj3WrOYvmJ/JxVPPndm1Eto9HncK/RgyZG10Ib1y gAuxnGwpLb1YAzBZhf6DMq7l2rKD12NP5F5Z2QwrLz+ddsMDKugz0uDkYpxCsg9cPGck ce6tlscI7EwqoY8T4tmzNrcI0qaXc3a1xnNyk8YVzk0Um2AcH9vlwG7SmOqfqJbHEDKJ gBeXDi13HKr8kDvKltX2mLHWGXkRLij7Zg2b6hq3GJ2dGYyM7ocCUxeA6k7Ct9sNcJ8E iHNj10fJndFoE9p6ISqSVpKJ9NjXTq4vXuXvIpJDzbalrGA87YXH354pwBXe0rACZuak 3Sxg== 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=qtouv6Z6Gh5nIAaDvGdVmaZJMnuDScOHiRWBgSzL7vs=; b=qWOTWU4mgLEou2r0QiSNk6GS3Vnh9S5V+/O+n+GTNwNpAHhPVlBoyGZwecvj/aW/TB taiyuoHP8n0LpiwkzNhGK/7NaLv/8bEUfH423gNVV/Rxwr7s/04J5vANTcx172r7KtKo CUsmuBILQ7TxM9cmGoQ6ZCpDJJQc5SFTXJ88zSwGE8HQGG74AtpKGVlM2Pi8wtPIPFSS 3kO2PlzdtIFQ9ho+H4pe/OWgO9jwS2GFxoJZ9XmkUabeKML2QMT9FHE8vvqwJwzuz+Yn F2ic/aD1Z0Ps2kGYrb8wvqow4v/ThHYh4bT+kNPNudzoCktI9zFO4zxhBnCRauw4kOSe MLug== X-Gm-Message-State: AO0yUKUkTzH5qM8jUtc6IITH0x1mvwaMz7fKLlc3ocFCyE00q9sGIheg k/t4GD44nIOVTRz81e8KDti7BmRMTO12shO2OT3v4Q== X-Google-Smtp-Source: AK7set/1hpxNVHlFIAFcnSPfgMcdJgv+C7gc3wU/4TGtqW8mjpZXmVYc0HKBp1hxQxUFwUzdaARiCeiMlJXlQofVbTk= X-Received: by 2002:a17:902:82c6:b0:196:cca:a0b4 with SMTP id u6-20020a17090282c600b001960ccaa0b4mr2367989plz.20.1674839910675; Fri, 27 Jan 2023 09:18:30 -0800 (PST) MIME-Version: 1.0 References: <167482734243.892262.18210955230092032606.stgit@firesoul> <87cz70krjv.fsf@toke.dk> In-Reply-To: <87cz70krjv.fsf@toke.dk> From: Stanislav Fomichev Date: Fri, 27 Jan 2023 09:18:19 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: YWVPERZKDUDF2WTQMOEPKOK6M2TLA6R3 X-Message-ID-Hash: YWVPERZKDUDF2WTQMOEPKOK6M2TLA6R3 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: Jesper Dangaard Brouer , 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 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 o= f > > the availability of rx_timestamp and rx_hash in data_meta area. The > > kernel-side BPF-prog code doesn't initialize these members when kernel > > returns an error e.g. -EOPNOTSUPP. This memory area is not guaranteed = to > > be zeroed, and can contain garbage/previous values, which will be read > > 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 it > > 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=3D= 8000 > > 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 supporte= d > > 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 marking > > 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 react > to failures; that's what the return code is there for, after all :) +1 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. > -Toke >