03/10/2025 12:29, Loftus, Ciara: > > > > 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. > > > > [...] > > > > > > 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?
It is confusing to add an API if it is a perfect overlap of what exists already. If you want to add a new API, you need to explain how it is different of a combination of reset/configure/start.
