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

[Bruce Richardson <bruce.richardson@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".

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

/Bruce