Re: [PATCH v4 net-next 00/15] net: enetc: SR-IOV improvements and ENETC v4 VF support

[Paolo Abeni]

On 9/9/26 12:07 PM, wei.fang@xxxxxxxxxxx wrote:
> From: Wei Fang <wei.fang@xxxxxxx>
> 
> This series enhances SR-IOV support for ENETC v1 and adds VF support
> for ENETC v4. For ENETC v1, the trusted VF management and per-VF
> configuration query via ndo_get_vf_config() are added. For ENETC v4,
> preliminary VF support is introduced for i.MX94 and i.MX95 platforms.
> 
> On the PF side, the series introduces trust level management and MAC
> address assignment for VFs, and implements ndo_get_vf_config() so that
> userspace tools such as 'ip link show' can query the current per-VF
> configuration. The PSI-to-VSI messaging infrastructure is extended to
> handle link status and link speed queries from VFs, enabling DPDK-owned
> VFs to obtain accurate link information from the PF.
> 
> On the VF side, MAC address filtering is implemented via the VSI-to-PSI
> mailbox, supporting both unicast/multicast hash filters and promiscuous
> mode control. Since the ndo_set_rx_mode callback is invoked with BH
> disabled and is incompatible with the mailbox polling path,
> ndo_set_rx_mode_async is used instead. Link status notifications are also
> supported: the VF registers with the PF and receives PSI-to-VSI messages
> on every PF link transition, keeping the VF carrier state in sync without
> polling.
> 
> VF Function Level Reset is handled explicitly to restore the PF-managed
> MAC promiscuous policy after each reset, since the hardware default after
> FLR enables promiscuous mode regardless of the policy set by the PF
> driver.
> 
> Several preparatory refactors are included to share infrastructure
> between the PF and VF drivers, such as moving msg_task and mac_filter
> from struct enetc_pf into the common struct enetc_si.
Most of clashiko feedback is around the consequence of the 200ms latency
introduced by link state notification. Given your replies I understand is
a well understood compromise/design decision.

I think the better option is merge the series as-is and eventually
follow-up as need would arise.

/P