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.129.124]) by mail.toke.dk (Postfix) with ESMTPS id EC0B09EAE43 for ; Fri, 17 Feb 2023 21:49:26 +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=BWBLieiQ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676666964; 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: in-reply-to:in-reply-to:references:references; bh=HPpXeHE7yIpnwoVN+RSEHBL4ndqdA5mUvILcECe2pZs=; b=BWBLieiQN4Kh7pHwIXjtftctFp7+oD2k5XSkEizC26ecG0BB3iEldlYfJDK0AcAEwCVaH7 M435nMyLS61BqDwzUch14iuZqC0EeoZtYwKc7wWpAuS3UR0wwCj8wFqzbAM0GaFLgYHgbS U/Je9PPsUamhKzuElshGcUPQSV+c3f4= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-615-GqLTJHs5MlaOhPjY8QSrsA-1; Fri, 17 Feb 2023 15:49:22 -0500 X-MC-Unique: GqLTJHs5MlaOhPjY8QSrsA-1 Received: by mail-ed1-f70.google.com with SMTP id q12-20020a056402518c00b004ace822b750so3400325edd.20 for ; Fri, 17 Feb 2023 12:49:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=HPpXeHE7yIpnwoVN+RSEHBL4ndqdA5mUvILcECe2pZs=; b=tomtiq38BrProww3RWqecBEcbHrtta7r/I0dVdlKg5nmNNm64YNh+K6mx/ENOSsHBd 1BSo0yRbSGATjqU0uQAbuM7eswN1KojZKQZRgqNvaVQ60WTvEIMdt2pJtg6hl59BhlpW UWTIU4eodRepG5eOGGFq54r+qW4f3wqraCx5tNG98RqaKyeHA/6Lndw/eDKjhaBisJMM 3X4ZWmCHRlO2nq3hp/wALlDKhrllTcxu+44MdGJQDmVMn2yBakvjoWXmv2Cdj28c3OPy xY72Y2xBfC2in5XKQ9ud6mpovHIx/gqpkiruOr1hrIh/U6lXOTu9uUHG170O1ItU23uk nUmA== X-Gm-Message-State: AO0yUKUBD9IRasm3rp4BHtvjB6huj4lvRbnKlCYvc2gsvIe4rxpWOdEd msnTxirZN02EC26I8htfjEkJ8MPLQ/FmF6mMCGUygqZU6jM3SxN+7CC/L3jAVdOh2rDpBOkPrNl EOfwzlJKjS6U1cuu/Pa3X X-Received: by 2002:a17:906:6d84:b0:87f:2d81:1d2a with SMTP id h4-20020a1709066d8400b0087f2d811d2amr1325420ejt.35.1676666961413; Fri, 17 Feb 2023 12:49:21 -0800 (PST) X-Google-Smtp-Source: AK7set/Wu74Ud4NsNvjllIQkdpd0JezWa+v3sHmHVHdl+b9b154S4zTinLDgzvLbQq0rj42RB+Jqvw== X-Received: by 2002:a17:906:6d84:b0:87f:2d81:1d2a with SMTP id h4-20020a1709066d8400b0087f2d811d2amr1325387ejt.35.1676666960966; Fri, 17 Feb 2023 12:49:20 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([45.145.92.2]) by smtp.gmail.com with ESMTPSA id p8-20020a170906838800b0088f8abd3214sm2551770ejx.92.2023.02.17.12.49.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Feb 2023 12:49:20 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 073D59748D9; Fri, 17 Feb 2023 21:49:20 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Stanislav Fomichev , Martin KaFai Lau In-Reply-To: References: <167663589722.1933643.15760680115820248363.stgit@firesoul> <514bb57b-cc3e-7b7e-c7d4-94cdf52565d6@linux.dev> X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 17 Feb 2023 21:49:19 +0100 Message-ID: <87mt5cow4w.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Message-ID-Hash: WD3O6SOL6LIIPEL2GEGRXRU63C3MCETD X-Message-ID-Hash: WD3O6SOL6LIIPEL2GEGRXRU63C3MCETD 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: Jesper Dangaard Brouer , bpf@vger.kernel.org, netdev@vger.kernel.org, martin.lau@kernel.org, ast@kernel.org, daniel@iogearbox.net, alexandr.lobakin@intel.com, larysa.zaremba@intel.com, xdp-hints@xdp-project.net X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next V2] xdp: bpf_xdp_metadata use NODEV for no device support 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 Fri, Feb 17, 2023 at 9:55 AM Martin KaFai Lau wrote: >> >> On 2/17/23 9:40 AM, Stanislav Fomichev wrote: >> > On Fri, Feb 17, 2023 at 9:39 AM Martin KaFai Lau wrote: >> >> >> >> On 2/17/23 9:32 AM, Stanislav Fomichev wrote: >> >>> On 02/17, Jesper Dangaard Brouer wrote: >> >>>> With our XDP-hints kfunc approach, where individual drivers overload the >> >>>> default implementation, it can be hard for API users to determine >> >>>> whether or not the current device driver have this kfunc available. >> >>> >> >>>> Change the default implementations to use an errno (ENODEV), that >> >>>> drivers shouldn't return, to make it possible for BPF runtime to >> >>>> determine if bpf kfunc for xdp metadata isn't implemented by driver. >> >>> >> >>>> This is intended to ease supporting and troubleshooting setups. E.g. >> >>>> when users on mailing list report -19 (ENODEV) as an error, then we can >> >>>> immediately tell them their device driver is too old. >> >>> >> >>> I agree with the v1 comments that I'm not sure how it helps. >> >>> Why can't we update the doc in the same fashion and say that >> >>> the drivers shouldn't return EOPNOTSUPP? >> >>> >> >>> I'm fine with the change if you think it makes your/users life >> >>> easier. Although I don't really understand how. We can, as Toke >> >>> mentioned, ask the users to provide jited program dump if it's >> >>> mostly about user reports. >> >> >> >> and there is xdp-features also. >> > >> > Yeah, I was going to suggest it, but then I wasn't sure how to >> > reconcile our 'kfunc is not a uapi' with xdp-features (that probably >> > is a uapi)? >> >> uapi concern is a bit in xdp-features may go away because the kfunc may go away ? > > Yeah, if it's another kind of bitmask we'd have to retain those bits > (in case of a particular kfunc ever going away).. > >> May be a list of xdp kfunc names that it supports? A list of kfunc btf id will >> do also and the user space will need to map it back. Not sure if it is easily >> doable in xdp-features. > > Good point. A string list / btf_id list of kfuncs implemented by > netdev might be a good alternative. Yup, Lorenzo and I discussed something similar at one point, I think having this as part of the feature thing would be useful! -Toke