On Wed, 29 Jul 2020 17:54:08 +0300 Moshe Shemesh wrote:
On 7/28/2020 11:06 PM, Jakub Kicinski wrote:Note that there is no driver reload in my examples, driver reload is
On Tue, 28 Jul 2020 12:18:30 -0700 Jacob Keller wrote:What about the support of these combinations, one device needs to reset
On 7/28/2020 11:44 AM, Jakub Kicinski wrote:Actually the default should probably be the combination of
From user perspective what's important is what the reset achieves (andWhere today "driver-param-init" is the default behavior. But didn't we
perhaps how destructive it is). We can define the reset levels as:
$ devlink dev reload pci/0000:82:00.0 net-ns-respawn
$ devlink dev reload pci/0000:82:00.0 driver-param-init
$ devlink dev reload pci/0000:82:00.0 fw-activate
combining should be possible when user wants multiple things to happen:
$ devlink dev reload pci/0000:82:00.0 fw-activate driver-param-init
just say that mlxsw also does the equivalent of fw-activate?
driver-param-init and net-ns-respawn.
fw to apply the param init, while another device can apply param-init
without fw reset, but has to reload the driver for fw-reset.
So the support per driver will be a matrix of combinations ?
likely not user's goal. Whatever the driver needs to reset to satisfy
the goal is fair game IMO.
It's already the case that some drivers reset FW for param init and some
don't and nobody is complaining.
We should treat constraints separate (in this set we have the live
activation which is a constraint on the reload operation).
Can you give an example?My expectations would be that the driver must perform the lowestOK, but some combinations may still not be valid for specific driver
reset level possible that satisfies the requested functional change.
IOW driver may do more, in fact it should be acceptable for the
driver to always for a full HW reset (unless --live or other
constraint is specified).
even if it tries lowest level possible.