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

[Florian Fainelli <f.fainelli@gmail.com>]

CC Doug, Justin,

On 8/14/2024 5:32 PM, Jakub Kicinski wrote:
> On Tue, 13 Aug 2024 15:33:25 -0700 Maciej Żenczykowski wrote:
>> In order to save power (battery), most network hardware
>> designed for low power environments (ie. battery powered
>> devices) supports varying types of hardware/firmware offload
>> (filtering and/or generating replies) of incoming packets.
>>
>> The goal being to prevent device wakeups caused by ingress 'spam'.
>>
>> This is particularly true for wifi (especially phones/tablets),
>> but isn't actually wifi specific.  It can also be implemented
>> in wired nics (TV) or usb ethernet dongles.
>>
>> For examples TVs require this to keep power consumption
>> under (the EU mandated) 2 Watts while idle (display off),
>> while still being discoverable on the network.
> 
> Sounds sane, adding Florian, he mentioned MDNS at last netconf.

Yes this looks fine to me:

Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>

> Tho, wasn't there supposed to be a more granular API in Android
> to control such protocol offloads?

I still am unable to find a public link for the 
com.google.tv.mdnsoffload package that describes how we can offload mDNS 
records in ATV, but that was what I mentioned during netconf that we 
needed to program into the hardware. Ideally using an ethtool API TBD, 
or a cfg80211 one, rather than some custom ioctls() and what not.

> 
> You gotta find an upstream driver which implements this for us to merge.
> If Florian doesn't have any quick uses -- I think Intel ethernet drivers
> have private flags for enabling/disabling an LLDP agent. That could be
> another way..

Currently we have both bcmgenet and bcmasp support the WAKE_FILTER 
Wake-on-LAN specifier. Our configuration is typically done in user-space 
for mDNS with something like:

ethtool -N eth0 flow-type ether dst 33:33:00:00:00:fb action 
0xfffffffffffffffe user-def 0x320000 m 0xffffffffff000fff
ethtool -N eth0 flow-type ether dst 01:00:5e:00:00:fb action 
0xfffffffffffffffe user-def 0x1e0000 m 0xffffffffff000fff
ethtool -s eth0 wol f

I would offer that we wire up the tunable into bcmgenet and bcmasp and 
we'd make sure on our side that the respective firmware implementations 
behave accordingly, but the respective firmware implementations 
currently look at whether any network filter have been programmed into 
the hardware, and if so, they are using those for offload. So we do not 
really need the tunable in a way, but if we were to add it, then we 
would need to find a way to tell the firmware not to use the network 
filters. We liked our design because there is no kernel <=> firmware 
communication.

Hummm
-- 
Florian