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 <[email protected]> > Signed-off-by: Timothy Miskell <[email protected]> > --- > 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
