On 2/21/23 9:13 AM, Stanislav Fomichev wrote:
On Sat, Feb 18, 2023 at 7:34 AM Jesper Dangaard Brouer
<brouer@xxxxxxxxxx> wrote:
When driver doesn't implement a bpf_xdp_metadata kfunc the default
implementation returns EOPNOTSUPP, which indicate device driver doesn't
implement this kfunc.
Currently many drivers also return EOPNOTSUPP when the hint isn't
available. Instead change drivers to return ENODATA in these cases.
There can be natural cases why a driver doesn't provide any hardware
info for a specific hint, even on a frame to frame basis (e.g. PTP).
Lets keep these cases as separate return codes.
Long term probably still makes sense to export this info via xdp-features?
Not sure how long we can 100% ensure EOPNOTSUPP vs ENODATA convention :-)
I am also not sure if it makes the xdp-hints adoption easier for other drivers
by enforcing ENODATA or what other return values a driver should or should not
return while EOPNOTSUPP is a more common errno to use. May be the driver experts
can prove me wrong here.
iiuc, it is for debugging if the bpf prog has been patched with the driver's xdp
kfunc. Others have suggested method like dumping the bpf prog insn. It could
also trace the driver xdp kfunc and see if it is actually called. Why these
won't work?
Beside, it is more like a load time decision which should not need a runtime
return error value to decide. eg. With xdp-features, the bpf prog can check a
global const which can be set based on the query result from xdp-features. It
will then be dead code removed by verifier. This could also handle the older
kernel that does not have xdp-metadata support (ie. missing
bpf_xdp_metadata_rx_{timestamp,hash}).
