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

[Stephen Hemminger <stephen@networkplumber.org>]

[-- Attachment #1: Type: text/plain, Size: 3049 bytes --]

Like the idea of a flag argument to reset function.

On Tue, Sep 30, 2025, 02:07 Bruce Richardson <bruce.richardson@intel.com>
wrote:

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

[-- Attachment #2: Type: text/html, Size: 3843 bytes --]