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)
