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

["Loftus, Ciara" <ciara.loftus@intel.com>]

> 
> >
> > 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@intel.com>
> > > Signed-off-by: Timothy Miskell <timothy.miskell@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.

I've submitted a v2 and renamed the function to "restore" instead of "reset" to
better describe the behaviour of the function - not just resetting, but also
restoring configuration afterwards and restarting the device.

I agree that it would be best to avoid a driver-specific function like this. After some
thought I don't think we can extend the reset API to include this behaviour, the
reset API should probably leave the device in a reset state.

I'm wondering if the community would be in favour of creating a new ethdev API
for restoring/reinitialising a device. It would essentially comprise of reset,
reconfigure and queue setup, and optionally device start?

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