From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Larysa Zaremba <larysa.zaremba@intel.com>,
bpf@vger.kernel.org, netdev@vger.kernel.org,
Stanislav Fomichev <sdf@google.com>,
martin.lau@kernel.org, ast@kernel.org, daniel@iogearbox.net,
alexandr.lobakin@intel.com, xdp-hints@xdp-project.net
Subject: [xdp-hints] Re: [PATCH bpf-next V1] xdp: bpf_xdp_metadata use NODEV for no device support
Date: Wed, 15 Feb 2023 18:11:48 +0100 [thread overview]
Message-ID: <c9be8991-1186-ef0f-449c-f2dd5046ca02@intel.com> (raw)
In-Reply-To: <Y+z9/Wg7RZ3wJ8LZ@lincoln>
From: Zaremba, Larysa <larysa.zaremba@intel.com>
Date: Wed, 15 Feb 2023 16:45:18 +0100
> On Wed, Feb 15, 2023 at 11:09:36AM +0100, 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.
>
> I think it diverts ENODEV usage from its original purpose too much. Maybe
> providing information in dmesg would be a better solution?
+1, -%ENODEV shouldn't be used here. It stands for "no device", for
example the driver probing core doesn't treat it as an error or that
something is not supported (rather than there's no device installed
in a slot / on a bus etc.).
>
>>
>> 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 kernel is too old.
>
> Do you mean driver being too old, not kernel?
>
>>
>> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
>> ---
[...]
Thanks,
Olek
next prev parent reply other threads:[~2023-02-15 17:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-15 10:09 [xdp-hints] " Jesper Dangaard Brouer
2023-02-15 15:45 ` [xdp-hints] " Larysa Zaremba
2023-02-15 17:11 ` Alexander Lobakin [this message]
2023-02-15 17:50 ` Jesper Dangaard Brouer
2023-02-16 11:33 ` Alexander Lobakin
2023-02-16 12:16 ` Larysa Zaremba
2023-02-16 14:13 ` Toke Høiland-Jørgensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.xdp-project.net/postorius/lists/xdp-hints.xdp-project.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c9be8991-1186-ef0f-449c-f2dd5046ca02@intel.com \
--to=aleksander.lobakin@intel.com \
--cc=alexandr.lobakin@intel.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=larysa.zaremba@intel.com \
--cc=martin.lau@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sdf@google.com \
--cc=xdp-hints@xdp-project.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox