All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin KaFai Lau <martin.lau@linux.dev>
To: Stanislav Fomichev <sdf@google.com>,
	Jesper Dangaard Brouer <brouer@redhat.com>
Cc: 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
Subject: Re: [PATCH bpf-next V2] xdp: bpf_xdp_metadata use NODEV for no device support
Date: Fri, 17 Feb 2023 09:38:54 -0800	[thread overview]
Message-ID: <514bb57b-cc3e-7b7e-c7d4-94cdf52565d6@linux.dev> (raw)
In-Reply-To: <Y++6IvP+PloUrCxs@google.com>

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.


  reply	other threads:[~2023-02-17 17:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-17 12:11 [PATCH bpf-next V2] xdp: bpf_xdp_metadata use NODEV for no device support Jesper Dangaard Brouer
2023-02-17 17:32 ` Stanislav Fomichev
2023-02-17 17:38   ` Martin KaFai Lau [this message]
2023-02-17 17:40     ` Stanislav Fomichev
2023-02-17 17:55       ` Martin KaFai Lau
2023-02-17 18:01         ` Stanislav Fomichev
2023-02-17 20:49           ` [xdp-hints] " Toke Høiland-Jørgensen
2023-02-18 14:01             ` Jesper Dangaard Brouer

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=514bb57b-cc3e-7b7e-c7d4-94cdf52565d6@linux.dev \
    --to=martin.lau@linux.dev \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.