RE: [PATCH v3 net-next 03/15] net: enetc: add link status message support to PF driver

[Wei Fang]

Best Regards,
Wei Fang
> On Tue, Sep 01, 2026 at 02:31:21AM +0000, Wei Fang wrote:
> > > > Add link status message support to the PF driver using three command IDs
> > > > under message class 0x80 (ENETC_MSG_CLASS_ID_LINK_STATUS):
> > > >
> > > > 1. ENETC_MSG_GET_CURRENT_LINK_STATUS (cmd_id 0)
> > > > The VF queries the current PF link status synchronously. This command is
> > > > not used by the Linux VF driver but is intended for DPDK-owned VFs.
> > > >
> > > > 2. ENETC_MSG_REGISTER_LINK_CHANGE_NOTIFIER (cmd_id 1)
> > > > The VF registers for link change notification. Upon registration, the PF
> > > > immediately notifies the VF of the current link status via a PSI-to-VSI
> > > > message, and continues to do so on every subsequent link state change.
> > > >
> > > > 3. ENETC_MSG_UNREGISTER_LINK_CHANGE_NOTIFIER (cmd_id 2)
> > > > The VF unregisters from link change notification.
> > > >
> > > > For link status message, the PSI-to-VSI message is 16 bits wide: the
> > > > upper 8 bits carry the message class ID, and the lower 8 bits carry the
> > > > class code. Bit 0 of the class code indicates the link state (1 = link
> > > > down, 0 = link up), and bit 1 indicates whether TX PAUSE is enabled on
> > > > the PF (1 = enabled, 0 = disabled).
> > > >
> > > > The TX PAUSE state is included because VF RX BD rings support congestion
> > > > mode, but whether the hardware can actually send PAUSE frames depends
> on
> > > > whether TX PAUSE is enabled on the PF. By conveying the PF TX PAUSE
> state
> > > > in the link status message, the VF can determine whether to enable
> > > > congestion mode on its RX BD rings.
> > >
> > > I see you have hit the 15 patch limit. Do you have a patch in the next
> > > series implementing ethtool get and set pause?
> > >
> >
> > No, we do not have the patch to support ethtool get and set pause for VF.
> > The link is controlled by the PF, including TX PAUSE-related configurations
> > (ON/OFF/refresh threshold and PAUSE Quanta). The VF can only passively
> > decide whether to enable congestion mode based on the actual link status.
> > Adding an ethtool set pause interface to the VF is meaningless because it
> > cannot control the link or configure TX PAUSE, , or rather, it shouldn't control
> > these.
> 
> Well, get will return what is actually happening. That could be
> useful.

You are right, I will consider adding a get interface, but that should be done
after this series is received. Thanks.

> 
> And from what you described, it sounds like the VF has the option to
> not enable congestion mode, i.e. not send pause frames. So you can
> implement a limited set, returning -EOPNOTSUPP under many conditions,
> but still allow some control. But it might not be worth it.
>