From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out2.migadu.com (out2.migadu.com [IPv6:2001:41d0:2:aacc::]) by mail.toke.dk (Postfix) with ESMTPS id 3F7F09EAD64 for ; Fri, 17 Feb 2023 18:55:37 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (1024-bit key; unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=nUX8RkVd Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1676656533; 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=qcwStO1IrRIdu/NB2fFOg3ZDGPu58pyI4+Iipe1H9kg=; b=nUX8RkVdQGWvd1CFwHayPpY9clPjGFV/OT2GnuIio9OTKWmGG0Fp+BkAc7+5sq134osjEE XCiC/yGcqUfua820YfFfKjsSRa64+nCsW0xYjp1//U0mwFiEFaemMmLRLq7gWbUw7Sv9gy 9KC25pWZuq14nWhtXFhq1lzGqvBUNj0= Date: Fri, 17 Feb 2023 09:55:30 -0800 MIME-Version: 1.0 Content-Language: en-US To: Stanislav Fomichev References: <167663589722.1933643.15760680115820248363.stgit@firesoul> <514bb57b-cc3e-7b7e-c7d4-94cdf52565d6@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Martin KaFai Lau In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT Message-ID-Hash: BYDXQGZODWH5BQTVNMTKV7LPG5X2MRLT X-Message-ID-Hash: BYDXQGZODWH5BQTVNMTKV7LPG5X2MRLT X-MailFrom: martin.lau@linux.dev 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: 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 ? 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.