From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by mail.toke.dk (Postfix) with ESMTPS id 0DA4B9C8BBC for ; Wed, 30 Nov 2022 21:17:52 +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=oyjPOqyv Received: by mail-oi1-x231.google.com with SMTP id h132so20017572oif.2 for ; Wed, 30 Nov 2022 12:17:52 -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=lf9T1oLTLGP7W1nyGzAWDJnXj7/p/jhbbGGie8srQTE=; b=oyjPOqyvujryB0noATPgxFc1sZrUuyqCS42aJvokKs436/eoSp+6+rX5OnvbD/yudk V4iUo/Vniin/nJ/YbejysoUYCSCNFrm2tr2Z6r3quoycxz9Er1VHsCEflLBrCgbUlwDS T5hMQ69PojAo5M1RCFf7Adfgt31nFng5t1rPIBBTWwTzD72JVPXkOWztq0BHsZFYDD+u 9fZoJ+eLrQRK86s5hN34vPDG1190r1SkDHKB6JixGV2EwoaNeLsqH0beSMFQGQw7qJNd xfSzNQYPtYnWhhf4EFvcAP2oOcF0lItBfNJYqM6YiZsl7Mz4rJXxDc+9yKmDhsQMZV/d Q/xQ== 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=lf9T1oLTLGP7W1nyGzAWDJnXj7/p/jhbbGGie8srQTE=; b=eT4AuF5L08SuWNzB2tctciDAMI9yULD9f8RNm/xCrbyuLyuH6QSI/Bb58xFCruijsf K8emfvhyw5eixCYxoaOXjILklj18nbV1VmWTTUnlk/xmh0BQ+W8H0FfXf7GDonPI1uVY gxPthwCkE+XBi3lUhN3XW+pd0yBT1taizSWD+1aYeB3hrt9uqvi+5gBn95Hy03hpMeIj cu1AQ/jtY7MzbnZH6PDl7RRURfGagGR8Ms8u4CMxlJ/ZmMd5QgL0fwBNLfUH4CvHN0yY 9W05Mf0W+lHHgF5Q5MZ+x/fURC/jGPCw9EEIMEvn0uoVrfyoM6VLLsQySX6JZ/0Kid1b RkkA== X-Gm-Message-State: ANoB5pnaZZxJkuknoZZiH+AWBKgiDyxHoDtY8fSUQNeqnPYC0usTYb2H SHGc3zQBmKqPkocc+ctIjrvwBTPOzm0fZQdbjUevdw== X-Google-Smtp-Source: AA0mqf58r7hvvVKvPt+x5p4U9j23auwntSydB7vAJx+mEf6lB9a3wE0iSXe0uiA5Oj5jDTqA693mK202zDElOVGC9bM= X-Received: by 2002:aca:d01:0:b0:35b:d6f7:c569 with SMTP id 1-20020aca0d01000000b0035bd6f7c569mr1552485oin.125.1669839470579; Wed, 30 Nov 2022 12:17:50 -0800 (PST) MIME-Version: 1.0 References: <20221121182552.2152891-1-sdf@google.com> <20221121182552.2152891-3-sdf@google.com> In-Reply-To: From: Stanislav Fomichev Date: Wed, 30 Nov 2022 12:17:39 -0800 Message-ID: To: Larysa Zaremba Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: SQO4X6TPVHQ243BC3BAWMKC4HVQ6366G X-Message-ID-Hash: SQO4X6TPVHQ243BC3BAWMKC4HVQ6366G 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 2/8] bpf: XDP metadata RX kfuncs List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, Nov 30, 2022 at 11:06 AM Stanislav Fomichev wrote: > > On Wed, Nov 30, 2022 at 9:38 AM Larysa Zaremba wrote: > > > > On Mon, Nov 21, 2022 at 10:25:46AM -0800, Stanislav Fomichev wrote: > > > > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > > > index 9528a066cfa5..315876fa9d30 100644 > > > --- a/kernel/bpf/verifier.c > > > +++ b/kernel/bpf/verifier.c > > > @@ -15171,6 +15171,25 @@ static int fixup_call_args(struct bpf_verifier_env *env) > > > return err; > > > } > > > > > > +static int fixup_xdp_kfunc_call(struct bpf_verifier_env *env, u32 func_id) > > > +{ > > > + struct bpf_prog_aux *aux = env->prog->aux; > > > + void *resolved = NULL; > > > > First I would like to say I really like the kfunc hints impementation. > > > > I am currently trying to test possible performace benefits of the unrolled > > version in the ice driver. I was working on top of the RFC v2, > > when I noticed a problem that also persists in this newer version. > > > > For debugging purposes, I have put the following logs in this place in code. > > > > printk(KERN_ERR "func_id=%u\n", func_id); > > printk(KERN_ERR "XDP_METADATA_KFUNC_RX_TIMESTAMP_SUPPORTED=%u\n", > > xdp_metadata_kfunc_id(XDP_METADATA_KFUNC_RX_TIMESTAMP_SUPPORTED)); > > printk(KERN_ERR "XDP_METADATA_KFUNC_RX_TIMESTAMP=%u\n", > > xdp_metadata_kfunc_id(XDP_METADATA_KFUNC_RX_TIMESTAMP)); > > printk(KERN_ERR "XDP_METADATA_KFUNC_RX_HASH_SUPPORTED=%u\n", > > xdp_metadata_kfunc_id(XDP_METADATA_KFUNC_RX_HASH_SUPPORTED)); > > printk(KERN_ERR "XDP_METADATA_KFUNC_RX_HASH=%u\n", > > xdp_metadata_kfunc_id(XDP_METADATA_KFUNC_RX_HASH)); > > > > Loading the program, which uses bpf_xdp_metadata_rx_timestamp_supported() > > and bpf_xdp_metadata_rx_timestamp(), has resulted in such messages: > > > > [ 412.611888] func_id=108131 > > [ 412.611891] XDP_METADATA_KFUNC_RX_TIMESTAMP_SUPPORTED=108126 > > [ 412.611892] XDP_METADATA_KFUNC_RX_TIMESTAMP=108128 > > [ 412.611892] XDP_METADATA_KFUNC_RX_HASH_SUPPORTED=108130 > > [ 412.611893] XDP_METADATA_KFUNC_RX_HASH=108131 > > [ 412.611894] func_id=108130 > > [ 412.611894] XDP_METADATA_KFUNC_RX_TIMESTAMP_SUPPORTED=108126 > > [ 412.611895] XDP_METADATA_KFUNC_RX_TIMESTAMP=108128 > > [ 412.611895] XDP_METADATA_KFUNC_RX_HASH_SUPPORTED=108130 > > [ 412.611895] XDP_METADATA_KFUNC_RX_HASH=108131 > > > > As you can see, I've got 108131 and 108130 IDs in program, > > while 108126 and 108128 would be more reasonable. > > It's hard to proceed with the implementation, when IDs cannot be sustainably > > compared. > > Thanks for the report! > Toke has reported a similar issue in [0], have you tried his patch? > I've also tried to address it in v3 [1], could you retry on top of it? > I'll try to insert your printk in my local build to see what happens > with btf ids on my side. Will get back to you.. > > 0: https://lore.kernel.org/bpf/87mt8e2a69.fsf@toke.dk/ > 1: https://lore.kernel.org/bpf/20221129193452.3448944-3-sdf@google.com/T/#u Nope, even if I go back to v2, I still can't reproduce locally. Somehow in my setup they are sorted properly :-/ Would appreciate it if you can test the v3 patch and confirm whether it's fixed on your side or not. > > Furthermore, dumped vmlinux BTF shows the IDs is in the exactly reversed > > order: > > > > [108126] FUNC 'bpf_xdp_metadata_rx_hash' type_id=108125 linkage=static > > [108128] FUNC 'bpf_xdp_metadata_rx_hash_supported' type_id=108127 linkage=static > > [108130] FUNC 'bpf_xdp_metadata_rx_timestamp' type_id=108129 linkage=static > > [108131] FUNC 'bpf_xdp_metadata_rx_timestamp_supported' type_id=108127 linkage=static > > > > > + > > > + if (func_id == xdp_metadata_kfunc_id(XDP_METADATA_KFUNC_RX_TIMESTAMP_SUPPORTED)) > > > + resolved = aux->xdp_netdev->netdev_ops->ndo_xdp_rx_timestamp_supported; > > > + else if (func_id == xdp_metadata_kfunc_id(XDP_METADATA_KFUNC_RX_TIMESTAMP)) > > > + resolved = aux->xdp_netdev->netdev_ops->ndo_xdp_rx_timestamp; > > > + else if (func_id == xdp_metadata_kfunc_id(XDP_METADATA_KFUNC_RX_HASH_SUPPORTED)) > > > + resolved = aux->xdp_netdev->netdev_ops->ndo_xdp_rx_hash_supported; > > > + else if (func_id == xdp_metadata_kfunc_id(XDP_METADATA_KFUNC_RX_HASH)) > > > + resolved = aux->xdp_netdev->netdev_ops->ndo_xdp_rx_hash; > > > + > > > + if (resolved) > > > + return BPF_CALL_IMM(resolved); > > > + return 0; > > > +} > > > + > > > > My working tree (based on this version) is available on github [0]. Situation > > is also described in the last commit message. > > I would be great, if you could check, whether this behaviour can be reproduced > > on your setup. > > > > [0] https://github.com/walking-machine/linux/tree/hints-v2