[xdp-hints] Re: [PATCH bpf-next V3] xdp: bpf_xdp_metadata use EOPNOTSUPP for no driver support

[Martin KaFai Lau <martin.lau@linux.dev>]

On 2/21/23 9:13 AM, Stanislav Fomichev wrote:
> On Sat, Feb 18, 2023 at 7:34 AM Jesper Dangaard Brouer
> <brouer@redhat.com> 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}).