From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by mail.toke.dk (Postfix) with ESMTPS id 2952C9EAD7E for ; Fri, 17 Feb 2023 19:01:54 +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=fdGbWL0J Received: by mail-pf1-x435.google.com with SMTP id x8so1134993pfh.3 for ; Fri, 17 Feb 2023 10:01:54 -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=6SRhPAA13aLvtcISjEh7UNd45/KaCXdcpSYC0/o7Tko=; b=fdGbWL0JuTEOclQuBV2JDCcz0weSJGNcRgguRpKPNklY/BdiEbwNBF0IhT41oRQaQS 5rAR9TO2DViX53mqj9/G6g5xonhnNCrCRFn1XiH0qGpdKZLI6IT7Ed6qF7yrsQwjRp0B GgPF/YG36JvZAsjBxlFgS5LqY49VSD7vgQoFlyfsJPsFoYrz7wZ67llYS7gdgsFru8yT Z3eYvhfyzASEEBlTmaeBvcaBZ2A20LnjZCgPOct1V31wL8svEfTcNujSHsDgS5R3HtAo sYUBHkspNwh46hbgOjeGiNV+HTKp/S/yRQkX3RTFSNOLqZrUdRM4OS/HfEteMSPw1Vgc +Hyg== 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=6SRhPAA13aLvtcISjEh7UNd45/KaCXdcpSYC0/o7Tko=; b=8ChkLeLUKRQQi2PW1DGi3XwLXlf+GVZAgdEpL2vOWSp34xFHP+xmphsK5lffjhRWL3 wkNCgssuqqPUw7zG6hSXEcxH3FUMD86d3iXSH50WsBBnK3EtHWbIhbIp30NsOJnB5vSB IsXqRkpDzxGgvOw5Cusd89QbsPdw3cs5H18Ah/J/b7G9942k6Z9v7IYqXQDIHRyoRLCF Ez0u89CEimThKI9if2rUwpWm4bjdQnTr0WH/40YeS4QQSiuOOwMxRJtlNOl10Bjbcb1q M612K6QQfwQFylxztsz9/XuNk8+zLks2TlvbukGyYUX9kvpfblC3CwYArQmBnVP536eG hPhg== X-Gm-Message-State: AO0yUKXeYqxitBpTXpL2hlBS9+eWN1QtvHaABaD2tJVbDO2Cjh0htFN6 17s32/SlNpy9f/qRLEBzhqSCCvsDzNf75EGuy2bSDg== X-Google-Smtp-Source: AK7set8RB8tCn0RLfyoUEz55zl/eOunKJ0SjnWLmsTgX0hArxXzp9JM0TPyn/3jcShUR9vTgPkQDPzaETF1RFPDb7Mo= X-Received: by 2002:a63:3644:0:b0:4ce:caaa:2696 with SMTP id d65-20020a633644000000b004cecaaa2696mr298227pga.1.1676656912332; Fri, 17 Feb 2023 10:01:52 -0800 (PST) MIME-Version: 1.0 References: <167663589722.1933643.15760680115820248363.stgit@firesoul> <514bb57b-cc3e-7b7e-c7d4-94cdf52565d6@linux.dev> In-Reply-To: From: Stanislav Fomichev Date: Fri, 17 Feb 2023 10:01:40 -0800 Message-ID: To: Martin KaFai Lau Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: PFW4RRMXZKAVJ2N4IPWNTZ7IEC5FLSKL X-Message-ID-Hash: PFW4RRMXZKAVJ2N4IPWNTZ7IEC5FLSKL 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: 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 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.