netdev - Re: [Intel-wired-lan] [PATCH iwl-next] ice: Implement ethtool reset support

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: <616bd069-51a0-4b05-96af-2d419961e0e5@intel.com>
Date: Thu, 1 Aug 2024 13:01:52 +0200
From: Wojciech Drewek <wojciech.drewek@...el.com>
To: Jakub Kicinski <kuba@...nel.org>, "Keller, Jacob E"
	<jacob.e.keller@...el.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "edumazet@...gle.com"
	<edumazet@...gle.com>, "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
	"simon.horman@...igine.com" <simon.horman@...igine.com>,
	"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next] ice: Implement ethtool reset
 support



On 01.08.2024 01:47, Jakub Kicinski wrote:
> On Wed, 31 Jul 2024 14:08:20 +0200 Wojciech Drewek wrote:
>> Quick summary our reset types:
>> PF reset reinitialize the resources/data path for PF and its VFs.
>> It has no impact on other PF/VFs.
>> Core Reset reinitialize all functions and shared parts of the
>> device except PHY/MAC units, EMP and PCI Interface.
>> Global Reset is Core Reset + PHY/MAC units reset (including External PHY)
>> Because Global Reset is a extended Core it makes sense to map it to all.
>> PF reset mapping makes sense to me since it is dedicated to a single physical function.
> 
> On Wed, 31 Jul 2024 09:48:07 -0700 Jacob Keller wrote:
>> PF reset only affects the single PCI function, and does not affect the
>> whole adapter. I don't know how it relates to PCIe resets precisely.
>>
>> CORE reset affects the whole adapter, and the other functions are
>> notified of the impending reset via their miscellaneous interrupt vector
>> in combination with some hardware registers.
>>
>> GLOBAL reset is similar to the CORE reset, (in that it affects the
>> entire device), but it is more invasive in the hardware. I cannot
>> remember offhand the differences between CORE and GLOBAL.
>>
>> There is also an EMP reset, which is the only reset that completely
>> reloads the EMP firmware. It is currently used by the device flash
>> update logic, via devlink reload and is only available if the new
>> firmware image can be reloaded without issue. (Reloading when the new
>> firmware could impact PCIe config space is likely to produce undesirable
>> behavior because the PCIe config space is not reloaded except by power
>> cycling, so you end up with some weird mismatches.)
> 
> Note that the reset is controlled using individual bits which can be
> combined:
> 
> 	ETH_RESET_MGMT		= 1 << 0,	/* Management processor */
> 	ETH_RESET_IRQ		= 1 << 1,	/* Interrupt requester */
> 	ETH_RESET_DMA		= 1 << 2,	/* DMA engine */
> 	ETH_RESET_FILTER	= 1 << 3,	/* Filtering/flow direction */
> 	ETH_RESET_OFFLOAD	= 1 << 4,	/* Protocol offload */
> 	ETH_RESET_MAC		= 1 << 5,	/* Media access controller */
> 	ETH_RESET_PHY		= 1 << 6,	/* Transceiver/PHY */
> 	ETH_RESET_RAM		= 1 << 7,	/* RAM shared between
> 						 * multiple components */
> 	ETH_RESET_AP		= 1 << 8,	/* Application processor */
> 
> 	ETH_RESET_DEDICATED	= 0x0000ffff,	/* All components dedicated to
> 						 * this interface */
> 	ETH_RESET_ALL		= 0xffffffff,	/* All components used by this
> 						 * interface, even if shared */
> 
> Note that ethtool CLI defines "shared" version of all bits as bits
> shifted up by 16. And it is forward compatible (accepts raw "flags")
> if we need to define new bits.
> 
> I guess in your case EMP == MGMT? So if these resets don't reset EMP
> I presume we shouldn't use any option that includes MGMT..
> 
> Could you express your resets in the correct combination of these bits
> instead of picking a single one?
> 

We've came up with below mapping:

PF reset:
ethtool --reset eth0 irq dma filter offload
(we reset all those components but only for the given PF)

CORE reset:
ethtool --reset eth0 irq-shared dma-shared filter-shared offload-shared ram-shared
(whole adapter is affected so we use shared versions + ram)

GLOBAL reset:
ethtool --reset eth0 irq-shared dma-shared filter-shared offload-shared mac-shared phy-shared ram-shared
(GLOBALR is CORER plus mac and phy components are also reinitialized)