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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240815084526.5b1975c3@kernel.org>
Date: Thu, 15 Aug 2024 08:45:26 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Maciej Żenczykowski <maze@...gle.com>, Doug Berger
 <opendmb@...il.com>, Justin Chen <justin.chen@...adcom.com>, Maciej
 Żenczykowski <zenczykowski@...il.com>, Linux Network
 Development Mailing List <netdev@...r.kernel.org>, "David S . Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, "Kory Maincent (Dent Project)"
 <kory.maincent@...tlin.com>, Ahmed Zaki <ahmed.zaki@...el.com>, Edward Cree
 <ecree.xilinx@...il.com>, Yuyang Huang <yuyanghuang@...gle.com>, Lorenzo
 Colitti <lorenzo@...gle.com>
Subject: Re: [PATCH net-next] ethtool: add tunable api to disable various
 firmware offloads

On Wed, 14 Aug 2024 20:08:05 -0700 Florian Fainelli wrote:
> > 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.

Hm, I may be lacking the practical exposure to such systems to say
anything sensible, but when has that ever stopped me..
IIUC you're saying that FW enables MLD offload if the wake filter is 
in place. But for ping/arp/igmp offload there's no need to wake, ever,
so there wouldn't be a filter?