Re: [PATCH net-next] ethtool: add tunable api to disable various firmware offloads

[Jakub Kicinski <kuba@kernel.org>]

On Thu, 15 Aug 2024 17:49:42 -0700 Maciej Żenczykowski wrote:
> I am of course in a very hard position here, as I don't own any
> drivers/firmware - AFAIK even Pixel's wifi/cell drivers aren't Google
> owned/maintained, but rather Broadcom/Synaptics/Qualcomm/Mediatek/etc
> as appropriate...
> 
> I do know there is a need for an api of this sort (not necessarily
> exactly this patch though), and if we merge something (sane :-) ) into
> Linux, we can then backport that (either to LTS or just to ACK), and
> then we (as in Google) can require implementations (for new
> hardware/drivers) in future versions of Android...

That's why I'm suggesting the LLDP in the Intel Ethernet driver.
Others may disagree but for me it's close enough to merge a "enable
L2 protocol agent" sort of an API. We don't need to have upstream users
for each proto. Bigger cause of sadness is that the API IIUC is a part
of a deprecation path, IOW once APF comes, it will become dead weight.
Luckily it's not a lot of code.

> Presumably that would result in implementations in many drivers,
> though not necessarily any in-tree ones (I have no idea what the
> current state of in-vs-out-of-tree drivers is wrt. Android wifi/cell
> hardware)
> 
> This is very much a chicken-and-egg problem though.  As long as there
> is no 'public' API, the default approach is for per-vendor or even
> per-chip / per-driver custom apis, hidden behind Android HALs.  For
> example we have such an Android HAL api for disabling ND offload on at
> least one of our devices.  Of course the HAL itself is backed by
> calling into the driver - just over some driver specific netlink...

I wonder if there's anything we can share between APF style offloads
and Jamal's P4 work, if it materializes.