On 2/17/23 9:40 AM, Stanislav Fomichev wrote:
On Fri, Feb 17, 2023 at 9:39 AM Martin KaFai Lau <martin.lau@xxxxxxxxx> 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.
