> > > > > 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". > > 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
