[PATCH 1/2] net/iavf: support VF initiated resets

[Loftus, Ciara]

> 
> On Mon, Sep 29, 2025 at 02:30:38PM +0000, Ciara Loftus wrote:
> > Introduce a function that allows a VF to request the PF to reset itself.
> > This is useful for example when the application detects that one of the
> > queues have hung or any event where a reset is required and the PF is
> > unlikely to trigger it.
> >
> > Signed-off-by: Ciara Loftus <ciara.loftus at intel.com>
> > Signed-off-by: Timothy Miskell <timothy.miskell at intel.com>
> > ---
> >  drivers/net/intel/iavf/iavf.h         |  2 ++
> >  drivers/net/intel/iavf/iavf_ethdev.c  |  5 ++++
> >  drivers/net/intel/iavf/iavf_vchnl.c   | 29 +++++++++++++++++++++++
> >  drivers/net/intel/iavf/meson.build    |  1 +
> >  drivers/net/intel/iavf/rte_pmd_iavf.c | 33
> +++++++++++++++++++++++++++
> >  drivers/net/intel/iavf/rte_pmd_iavf.h | 11 +++++++++
> >  6 files changed, 81 insertions(+)
> >  create mode 100644 drivers/net/intel/iavf/rte_pmd_iavf.c
> >
> > diff --git a/drivers/net/intel/iavf/iavf.h b/drivers/net/intel/iavf/iavf.h
> > index 435902fbc2..6e7aec1bb1 100644
> > --- a/drivers/net/intel/iavf/iavf.h
> > +++ b/drivers/net/intel/iavf/iavf.h
> > @@ -565,4 +565,6 @@ void iavf_dev_watchdog_enable(struct
> iavf_adapter *adapter);
> >  void iavf_dev_watchdog_disable(struct iavf_adapter *adapter);
> >  void iavf_handle_hw_reset(struct rte_eth_dev *dev);
> >  void iavf_set_no_poll(struct iavf_adapter *adapter, bool link_change);
> > +bool is_iavf_supported(struct rte_eth_dev *dev);
> > +int iavf_request_reset(struct rte_eth_dev *dev);
> >  #endif /* _IAVF_ETHDEV_H_ */
> 
> In general, I'm not a huge fan of adding driver-specific functions and I
> feel like this should fit under the existing reset APIs in some way. That
> should avoid the need to update (or such a big update) to testpmd, for
> example.
> Some thoughts here:
> 
> 1. we could add a devarg to the driver to adjust whether reset does a
>    "softer" reset of the VF just resetting itself, or a "hard" reset where the
>    PF does a fuller reset of the VF.
> 2. rather than a devarg, would do use a driver-specific function to adjust
>    this behaviour. The difference here would be that the driver-specific
>    function would be an init-time one rather than runtime, so the runtime of
>    the app, like testpmd, would be generic.
> 3. the most generic solution would be to add an additional parameter to the
>    reset() function itself to specify a hard or soft reset. This would mean
>    updating all drivers to handle the new parameter (shouldn't be hard, since
>    it would be __rte_unused in all cases by default). This also opens up
>    the possibility of other drivers - especially VFs - using it in the same
>    way. We could actually document that the "hard" option "may be used by VF
>    drivers to request a full reset of the VF by the PF".

Hi Bruce,

I did not make it clear in my commit messages the full purpose of this new API.
Along with resetting the VF, the VF is also reconfigured and restarted
transparently, using the existing iavf_handle_hw_reset implementation.
While there is probably merit in extending the reset API to include a soft/hard
reset flag, I would still need this new API to fulfil the purpose described above.
If we wanted to make this generic I see two options:
1. extend the reset API to optionally reconfigure and restart
2. introduce a new generic API that performs a reset followed by a reconfigure
and restart.

Thanks,
Ciara

> 
> CC'ing techboard to get some wider opinions here, especially thoughts on
> option #3.
> 
> /Bruce