On 01.08.2024 01:47, Jakub Kicinski wrote:

On Wed, 31 Jul 2024 14:08:20 +0200 Wojciech Drewek wrote:

quoted

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:

quoted

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)