On Wed, 16 Dec 2020 05:15:04 +0000 Parav Pandit wrote:
> > From: Jakub Kicinski <kuba@xxxxxxxxxx>
> > Sent: Wednesday, December 16, 2020 6:08 AM
> >
> > On Tue, 15 Dec 2020 01:03:48 -0800 Saeed Mahameed wrote:
> > > From: Parav Pandit <parav@xxxxxxxxxx>
> > >
> > > devlink port function can be in active or inactive state.
> > > Allow users to get and set port function's state.
> > >
> > > When the port function it activated, its operational state may change
> > > after a while when the device is created and driver binds to it.
> > > Similarly on deactivation flow.
> >
> > So what's the flow device should implement?
> >
> > User requests deactivated, the device sends a notification to the driver
> > bound to the device. What if the driver ignores it?
> >
> If driver ignores it, those devices are marked unusable for new allocation.
> Device becomes usable only after it has act on the event.
But the device remains fully operational?
So if I'm an admin who wants to unplug a misbehaving "entity"[1]
the deactivate is not gonna help me, it's just a graceful hint?
Is there no need for a forceful shutdown?
[1] refer to earlier email, IDK what entity is supposed to use this
> > > + * @DEVLINK_PORT_FUNCTION_OPSTATE_DETACHED: Driver is detached
> > from the function of port; it is
> > > + * safe to delete the port.
> > > + */
> > > +enum devlink_port_function_opstate {
> > > + DEVLINK_PORT_FUNCTION_OPSTATE_DETACHED,
> >
> > The port function must be some Mellanox speak - for the second time - I
> > have no idea what it means. Please use meaningful names.
> >
> It is not a Mellanox term.
> Port function object is the one that represents function behind this port.
> It is not a new term. Port function already exists in devlink whose operational state attribute is defined here.
I must have missed that in review. PCI functions can host multiple
ports. So "port function" does not compute for me. Can we drop the
"function"?
