From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) by mail.toke.dk (Postfix) with ESMTPS id 49DDE9EAD45 for ; Fri, 17 Feb 2023 18:40:57 +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=n7Jsjgkt Received: by mail-pg1-x52c.google.com with SMTP id 23so904265pgg.8 for ; Fri, 17 Feb 2023 09:40:57 -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=ubunDlU9msRDy+3uOkSF8XjE+wanE2T00XUNyd5oMi4=; b=n7JsjgktBMNQx/ldOcn9KJaPpxJY8SsZEOiU4Xo1R4zL6ExHCOj0Yj94XdW0J66mvc USpev9GnAFcZtOZrFrFbEKgWVItPVm6PYkyYUJRLjORlAKa83SlKVotqPfp8WaG9cIUx qXAxZkqcTRxCov0aQFpciyQLpCEcMzRXRNlL83ghhehWjmdfdXorYwDUcmx7oa9gRVPT siLvPyM+Zin7onvBc/X/dw4d8P3VJ1OQdX2VxRshwJRPM1xgejIi1lPHsk8IvhG/+orq ux52+anRax9gUa37WsbHP4ux/5sqBgefE8Wbf/igMNI/iC3pKuxoqaE1StOSuiq0dcqC RPKA== 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=ubunDlU9msRDy+3uOkSF8XjE+wanE2T00XUNyd5oMi4=; b=8Ns45BE2XxBA/HxSanEuia8l9x3QPaOj5FGYoQLd9Hd0rogEuOC8jCzXFn1BXtzsuN Fnp9EIKWUjEblXVmg2IGVvQxt51D1mseVYOKm2ug6A5bbt2UH2X1ujFxqofVaqbgLd64 RVGkziI8+qljarXOkwHN8GwDHs6a9E2P2I2y6u10uQxzTMQv71lQoqRhT/W674OzAs6W Q81pHoiOKhaNsH3h54D1pKKsXUtAFgZT7NbedRtRA8N6NaevmPEtC2wsayzdmM8NnrGE xCEQk5GCfRoPNrrRCuNYOGlSuQJstAs0oNns5nOTR76YhE9zO2VycMycaZNy2uBLSUwF 6RcA== X-Gm-Message-State: AO0yUKV01lRUlj8MQpXjpvUYaJFZ1j2G9m3lmRJ2h5x6Uu3hXfygPYpD 2dg+E9iK3kVuhrxqri0K2ZZlUkbksE6hr4mD2itHXw== X-Google-Smtp-Source: AK7set9SoDrlXc7kV0zAOGDzQwuHDlEYDM53FMBDlAsUKbE7egGCacsLce+wVUlPMffrnZ2XuTtPYBwCiEM8EXodpG4= X-Received: by 2002:aa7:8642:0:b0:5a9:c941:43d2 with SMTP id a2-20020aa78642000000b005a9c94143d2mr579538pfo.16.1676655655824; Fri, 17 Feb 2023 09:40:55 -0800 (PST) MIME-Version: 1.0 References: <167663589722.1933643.15760680115820248363.stgit@firesoul> <514bb57b-cc3e-7b7e-c7d4-94cdf52565d6@linux.dev> In-Reply-To: <514bb57b-cc3e-7b7e-c7d4-94cdf52565d6@linux.dev> From: Stanislav Fomichev Date: Fri, 17 Feb 2023 09:40:44 -0800 Message-ID: To: Martin KaFai Lau Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: 7O6Q73AYIFACF3GZBILQTRWN6SR73ALC X-Message-ID-Hash: 7O6Q73AYIFACF3GZBILQTRWN6SR73ALC 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: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)?