Re: [PATCH net-next 1/3] devlink: Introduce PCI PF port flavour and port attribute

[Jiri Pirko <jiri@resnulli.us>]

Wed, Jul 03, 2019 at 06:46:13AM CEST, parav@mellanox.com wrote:
>
>
>> -----Original Message-----
>> From: Jakub Kicinski <jakub.kicinski@netronome.com>
>> Sent: Wednesday, July 3, 2019 7:46 AM
>> To: Parav Pandit <parav@mellanox.com>
>> Cc: Jiri Pirko <jiri@mellanox.com>; netdev@vger.kernel.org; Saeed
>> Mahameed <saeedm@mellanox.com>
>> Subject: Re: [PATCH net-next 1/3] devlink: Introduce PCI PF port flavour and
>> port attribute
>> 
>> On Wed, 3 Jul 2019 02:08:39 +0000, Parav Pandit wrote:
>> > > If you want to expose some device specific eswitch port ID please
>> > > add a new attribute for that.
>> > > The fact that that ID may match port_number for your device today is
>> > > coincidental.  port_number, and split attributes should not be
>> > > exposed for PCI ports.
>> >
>> > So your concern is non mellanox hw has eswitch but there may not be a
>> > unique handle to identify a eswitch port?
>> 
>> That's not a concern, no.  Like any debug attribute it should be optional.
>> 
>> > Or that handle may be wider than 32-bit?
>> 
>> 64 bit would probably be better, yes, although that wasn't my initial
>> concern.
>> 
>Why 32-bit is not enough?
>
>> > And instead of treating port_number as handle, there should be
>> > different attribute, is that the ask?
>> 
>> Yes, the ask, as always, is to not abuse existing attributes to carry
>> tangentially related information.
>
>Why it is tangential?
>Devlink_port has got a port_number. Depending on flavour this port_number represents a port.
>If it is floavour=PHYSICAL, its physical port number.
>If it is eswitch pf/vf ports, it represents eswitch port.
>
>Why you see it only as physical_port_number?

The original intention was like that. See the desc of
devlink_port_attrs_set():

 *      @port_number: number of the port that is facing user, for example
 *                    the front panel port number

For vf/pf representors, this is not applicable and should be indeed
avoided.

However, we expose it for DEVLINK_PORT_FLAVOUR_CPU and
DEVLINK_PORT_FLAVOUR_DSA. Not sure if it makes sense there either.
Ccing Florian, Andrew and Vivien.
What do you guys think?

Perhaps we should have:
	if (attrs->flavour == DEVLINK_PORT_FLAVOUR_PHYSICAL &&
	    nla_put_u32(msg, DEVLINK_ATTR_PORT_NUMBER, attrs->port_number))
                return -EMSGSIZE;
in devlink_nl_port_attrs_put()