RE: [net-next v5 05/15] devlink: Support get and set state of port function

From: Parav Pandit <parav@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>, Saeed Mahameed <saeed@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Leon Romanovsky <leonro@nvidia.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	David Ahern <dsahern@kernel.org>,
	Jacob Keller <jacob.e.keller@intel.com>,
	Sridhar Samudrala <sridhar.samudrala@intel.com>,
	"david.m.ertman@intel.com" <david.m.ertman@intel.com>,
	"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
	"kiran.patil@intel.com" <kiran.patil@intel.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	Jiri Pirko <jiri@nvidia.com>, Vu Pham <vuhuong@nvidia.com>,
	Saeed Mahameed <saeedm@nvidia.com>
Subject: RE: [net-next v5 05/15] devlink: Support get and set state of port function
Date: Wed, 16 Dec 2020 05:15:04 +0000	[thread overview]
Message-ID: <BY5PR12MB43225346806029AA31D63918DCC50@BY5PR12MB4322.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20201215163747.4091ff61@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>


> From: Jakub Kicinski <kuba@kernel.org>
> Sent: Wednesday, December 16, 2020 6:08 AM
> 
> On Tue, 15 Dec 2020 01:03:48 -0800 Saeed Mahameed wrote:
> > From: Parav Pandit <parav@nvidia.com>
> >
> > 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.
 
> > $ devlink port function set pci/0000:06:00.0/32768 hw_addr
> > 00:00:00:00:88:88 state active
> 
> Is request to deactivate done by settings state to inactive?
>
Yes.
 
> > + * enum devlink_port_function_opstate - indicates operational state
> > + of port function
> > + * @DEVLINK_PORT_FUNCTION_OPSTATE_ATTACHED: Driver is attached
> to the
> > + function of port,
> 
> This name definitely needs to be shortened.
>
DEVLINK_PORT_FUNCTION_OPS_ATTACHED
Or
DEVLINK_PF_OPS_ATTACHED 

PF - port function
 
> > + *					    gracefufl tear down of the function,
> after
> 
> gracefufl
> 
> > + *					    inactivation of the port function,
> user should wait
> > + *					    for operational state to turn
> DETACHED.
> 
> Why do you indent the comment by 40 characters and then go over 80
> chars?
> 
Will fix it.

> > + * @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.
 
> > devlink_nl_port_function_attrs_put(struct sk_buff *msg, struct
> > devlink_port *por
> >
> >  	ops = devlink->ops;
> >  	err = devlink_port_function_hw_addr_fill(devlink, ops, port, msg,
> > extack, &msg_updated);
> 
> Wrap your code, please.
>
Sure, will do.