From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) by mail.toke.dk (Postfix) with ESMTPS id A59079C7FC4 for ; Tue, 29 Nov 2022 19:52:13 +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=jns2UII/ Received: by mail-ot1-x32a.google.com with SMTP id g51-20020a9d12b6000000b0066dbea0d203so9710236otg.6 for ; Tue, 29 Nov 2022 10:52:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3kF2nCQdOdeM0yEQntHiZkxLcE3fR6ySiL2Yyd/wQfM=; b=jns2UII/3MOr6u03VlH0aYlZrL2BxaAlUD35YaUqG9ooBxRq4s8+qxlazjDXX5ssmU F9EAU5tcGec81VL7TRXlSQcbu6h/GypuEId3vpvus9XrV5fU4W31Ug8r3NGuX6TvOx4r cB9YZsS1YiXHlG1GleKIsTfQg/KdkbBFw7JVDZ/ly9CMofMrN1fqO1XUnAY9O9YODAdQ v/Ze4QnEdpcebHK/4bHkDDPnlQHqcBPTKFBWgR7YcxHNk4mpOHQQu7lriAYX+oQ6epA5 PtmdnAdrjakhPPCcMu3tLhPsfxNOlw83J9UYKE/ndnvQIP7m1EuMAVgk+SJgBw9nVJ+Z rO6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=3kF2nCQdOdeM0yEQntHiZkxLcE3fR6ySiL2Yyd/wQfM=; b=syRGoBlWIUR9Sl8NVu5XLIkufWJUD5wKe+0v/bYLPMaLdi05+qhFMvI5yTFxasXDEl wW97cAVC1NqxPPhvgaT7gSQNJV0jgi1zfjCHYWNgiLi/AloLFgzal2ZAV1XKnjB9gyob DBpGNzoKmPCw7Iw5iDzrlECrY/HRF0qFU+pi0mxcDXxXN4zewY5AbJ+Lp3x7QUZD0xzU trFsxKCNoZg1OqtUGJV4bsU+JrJlxrm7y8JybeLjQQHfq2c0RUx5A6/YJT5otF2XTJ2z 4HSrWXcvsDZ3OjGyokn1ibOtisQV9/9vwl9sXmQ1qWhCA0o3bbKod0GBPHCg7LpI1O5D Fuag== X-Gm-Message-State: ANoB5pmzfyck9HRA393dxY/f9UgK1bskwoo8vbOltKkAM8hVgCDRnR0o ff3Fy56A/fYOodAdWeo8ioIYuSNI/rsJviwzbwrL8w== X-Google-Smtp-Source: AA0mqf5PNjZJ4M+HQqvAh5pFHk4PRfVe8hAgmMYTL8Xr1j4AKV6kMUhYr/UPCxnlsuHFFlbDvByCgjUvz/xpIGb9+Jk= X-Received: by 2002:a9d:282:0:b0:66c:794e:f8c6 with SMTP id 2-20020a9d0282000000b0066c794ef8c6mr29567989otl.343.1669747930995; Tue, 29 Nov 2022 10:52:10 -0800 (PST) MIME-Version: 1.0 References: <20221121182552.2152891-1-sdf@google.com> <20221121182552.2152891-6-sdf@google.com> In-Reply-To: From: Stanislav Fomichev Date: Tue, 29 Nov 2022 10:52:00 -0800 Message-ID: To: Anton Protopopov Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: Z676D6THPNTAQDCKS2FDLRPCY7MLO2TM X-Message-ID-Hash: Z676D6THPNTAQDCKS2FDLRPCY7MLO2TM 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: bpf@vger.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, kpsingh@kernel.org, haoluo@google.com, jolsa@kernel.org, David Ahern , Jakub Kicinski , Willem de Bruijn , Jesper Dangaard Brouer , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , xdp-hints@xdp-project.net, netdev@vger.kernel.org X-Mailman-Version: 3.3.7 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next v2 5/8] selftests/bpf: Verify xdp_metadata xdp->af_xdp path List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue, Nov 29, 2022 at 2:06 AM Anton Protopopov wrote: > > On 22/11/21 10:25, Stanislav Fomichev wrote: > > > > [...] > > > > + > > + if (bpf_xdp_metadata_rx_timestamp_supported(ctx)) > > + meta->rx_timestamp = bpf_xdp_metadata_rx_timestamp(ctx); > > + > > + if (bpf_xdp_metadata_rx_hash_supported(ctx)) > > + meta->rx_hash = bpf_xdp_metadata_rx_hash(ctx); > > Is there a case when F_supported and F are not called in a sequence? If not, > then you can join them: > > bool (*ndo_xdp_rx_timestamp)(const struct xdp_md *ctx, u64 *timestamp); > > so that a calling XDP program does one indirect call instead of two for one > field > > if (bpf_xdp_metadata_rx_timestamp(ctx, &meta->rx_timestamp)) { > /* ... couldn't get the timestamp */ > } The purpose of the original bpf_xdp_metadata_rx_hash_supported was to allow unrolling and support dropping some dead branches by the verifier. Since there is still a chance we might eventually unroll some of these, maybe it makes sense to keep as is?