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.133.124]) by mail.toke.dk (Postfix) with ESMTPS id 0E2BB9C778F for ; Mon, 28 Nov 2022 23:25:31 +0100 (CET) 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=gKNieXxx DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669674330; 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=1gUMJ1NtqdnUUHrnJHiM2wr0hsk99IqIkqkSTVib1hw=; b=gKNieXxxo3W2ks4hfx8O0xDNxExZIE5bkBmi5VO+d0Kwd13DT2qy8FUTYyyL2k9K+vNs1d 7ghUKoKbPAWR7HXdLZkLGp1x3WSwPGT+CA2+JppcJXzTLcQ06EomInC+13MDAuW89rqHnb AIr6sLDJ7f3zV2ohshO2bZ+TI+No6aI= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-86-wTTflYnoNoKx8grB9KUoVQ-1; Mon, 28 Nov 2022 17:25:26 -0500 X-MC-Unique: wTTflYnoNoKx8grB9KUoVQ-1 Received: by mail-ej1-f72.google.com with SMTP id hs42-20020a1709073eaa00b007c00fb5a509so1880811ejc.17 for ; Mon, 28 Nov 2022 14:25:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=esifUvS4rY25Js6P1Az3k3jokEJ6OjEKTAKMI9a6KbM=; b=rTZ74jIOWtjLmeySwXusQsU/DW9PFlbPmAFDdixjHb+Y9vb1O9mYTBSPl5SQdO8Spl eMg1mfP0q5Tqm0B3nQQLiqbsPps5EgvWNPCRa0FNipGYQUoCyLB5xbHR4CBlL5gpETsG +Wmqe7f/59WTX4rglQmTEyqJzmzFgY+Lx7UVY+NHnQDNZCDJD81XBFtL5mbNoCcOfs9s ISQi3TpG+x6NUAmrYdoQp0w0y/98fRJrG+zlmvltxs08FctfV/7wv4lpuWnagCr0HS2F asrSVfwS8yilFt7nMhEejQDmx+dZPkRLLC1qFARksAviky8dGkaVsoIZsXxoQoeIh7ru eq8w== X-Gm-Message-State: ANoB5plqiktNuuEG6fmchMRn2qhjygRVkJNJfiPiZe/Mxqv0kKu22+vW XZg5u8eZOwvJNkppaTeI6clX88JWPnB8sIwTDu47J13gTX3RStftEwVNrEXsB8IGN4ivdB+o3Q3 1C8KcraloooTo2+eWUQWE X-Received: by 2002:a17:906:6892:b0:78d:ab48:bc84 with SMTP id n18-20020a170906689200b0078dab48bc84mr9183531ejr.22.1669674325029; Mon, 28 Nov 2022 14:25:25 -0800 (PST) X-Google-Smtp-Source: AA0mqf6OCJ/Pgejoyv/p1k+ImioFvemvLHuM7p17Mrwjj7a0VNSDVjrd/Xmy9cF9wmodsOZsxMEB0g== X-Received: by 2002:a17:906:6892:b0:78d:ab48:bc84 with SMTP id n18-20020a170906689200b0078dab48bc84mr9183466ejr.22.1669674323990; Mon, 28 Nov 2022 14:25:23 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([2a0c:4d80:42:443::2]) by smtp.gmail.com with ESMTPSA id n17-20020a05640206d100b00459f4974128sm5581663edy.50.2022.11.28.14.25.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Nov 2022 14:25:23 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 04F0D7EBEA3; Mon, 28 Nov 2022 23:25:23 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Stanislav Fomichev In-Reply-To: References: <20221121182552.2152891-1-sdf@google.com> <20221121182552.2152891-3-sdf@google.com> <87mt8e2a69.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Mon, 28 Nov 2022 23:25:22 +0100 Message-ID: <87y1ruzpgt.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: O6ONEINLGPSBZVV4ZFD7Q4SC3TNLN5T7 X-Message-ID-Hash: O6ONEINLGPSBZVV4ZFD7Q4SC3TNLN5T7 X-MailFrom: toke@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: 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: Stanislav Fomichev writes: > On Mon, Nov 28, 2022 at 10:53 AM Stanislav Fomichev wrot= e: >> >> s >> >> On Fri, Nov 25, 2022 at 9:53 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> > >> > Stanislav Fomichev writes: >> > >> > > There is an ndo handler per kfunc, the verifier replaces a call to t= he >> > > generic kfunc with a call to the per-device one. >> > > >> > > For XDP, we define a new kfunc set (xdp_metadata_kfunc_ids) which >> > > implements all possible metatada kfuncs. Not all devices have to >> > > implement them. If kfunc is not supported by the target device, >> > > the default implementation is called instead. >> > >> > BTW, this "the default implementation is called instead" bit is not >> > included in this version... :) >> >> fixup_xdp_kfunc_call should return 0 when the device doesn't have a >> kfunc defined and should fallback to the default kfunc implementation, >> right? >> Or am I missing something? >> >> > [...] >> > >> > > +#ifdef CONFIG_DEBUG_INFO_BTF >> > > +BTF_SET8_START(xdp_metadata_kfunc_ids) >> > > +#define XDP_METADATA_KFUNC(name, str) BTF_ID_FLAGS(func, str, 0) >> > > +XDP_METADATA_KFUNC_xxx >> > > +#undef XDP_METADATA_KFUNC >> > > +BTF_SET8_END(xdp_metadata_kfunc_ids) >> > > + >> > > +static const struct btf_kfunc_id_set xdp_metadata_kfunc_set =3D { >> > > + .owner =3D THIS_MODULE, >> > > + .set =3D &xdp_metadata_kfunc_ids, >> > > +}; >> > > + >> > > +u32 xdp_metadata_kfunc_id(int id) >> > > +{ >> > > + return xdp_metadata_kfunc_ids.pairs[id].id; >> > > +} >> > > +EXPORT_SYMBOL_GPL(xdp_metadata_kfunc_id); >> > >> > So I was getting some really weird values when testing (always getting= a >> > timestamp value of '1'), and it turns out to be because this way of >> > looking up the ID doesn't work: The set is always sorted by the BTF ID= , >> > not the order it was defined. Which meant that the mapping code got th= e >> > functions mixed up, and would call a different one instead (so the >> > timestamp value I was getting was really the return value of >> > rx_hash_enabled()). >> > >> > I fixed it by building a secondary lookup table as below; feel free to >> > incorporate that (or if you can come up with a better way, go ahead!). >> >> Interesting, will take a closer look. I took this pattern from >> BTF_SOCK_TYPE_xxx, which means that 'sorting by btf-id' is something >> BTF_SET8_START specific... >> But if it's sorted, probably easier to do a bsearch over this table >> than to build another one? > > Ah, I see, there is no place to store an index :-( Maybe the following > is easier still? > > diff --git a/net/core/xdp.c b/net/core/xdp.c > index e43f7d4ef4cf..8240805bfdb7 100644 > --- a/net/core/xdp.c > +++ b/net/core/xdp.c > @@ -743,9 +743,15 @@ static const struct btf_kfunc_id_set > xdp_metadata_kfunc_set =3D { > .set =3D &xdp_metadata_kfunc_ids, > }; > > +BTF_ID_LIST(xdp_metadata_kfunc_ids_unsorted) > +#define XDP_METADATA_KFUNC(name, str) BTF_ID(func, str) > +XDP_METADATA_KFUNC_xxx > +#undef XDP_METADATA_KFUNC > + > u32 xdp_metadata_kfunc_id(int id) > { > - return xdp_metadata_kfunc_ids.pairs[id].id; > + /* xdp_metadata_kfunc_ids is sorted and can't be used */ > + return xdp_metadata_kfunc_ids_unsorted[id]; > } > EXPORT_SYMBOL_GPL(xdp_metadata_kfunc_id); Right, as long as having that extra list isn't problematic (does it make things show up twice somewhere or something like that? not really sure how that works), that is certainly simpler than what I came up with :) -Toke