Re: [PATCH net-next v2 2/8] devlink: Support add and delete devlink port

[Jacob Keller <jacob.e.keller@intel.com>]

On 9/17/2020 9:25 PM, Parav Pandit wrote:
>> From: Jacob Keller <jacob.e.keller@intel.com>
>> Sent: Friday, September 18, 2020 12:13 AM
>>
>>
>> On 9/17/2020 10:20 AM, Parav Pandit wrote:
>>> Extended devlink interface for the user to add and delete port.
>>> Extend devlink to connect user requests to driver to add/delete such
>>> port in the device.
>>>
>>> When driver routines are invoked, devlink instance lock is not held.
>>> This enables driver to perform several devlink objects registration,
>>> unregistration such as (port, health reporter, resource etc) by using
>>> exising devlink APIs.
>>> This also helps to uniformly used the code for port registration
>>> during driver unload and during port deletion initiated by user.
>>>
>>
>> Ok. Seems like a good goal to be able to share code uniformly between driver
>> load and new port creation.
>>
> Yes.
>  
>>> +static int devlink_nl_cmd_port_new_doit(struct sk_buff *skb, struct
>>> +genl_info *info) {
>>> +	struct netlink_ext_ack *extack = info->extack;
>>> +	struct devlink_port_new_attrs new_attrs = {};
>>> +	struct devlink *devlink = info->user_ptr[0];
>>> +
>>> +	if (!info->attrs[DEVLINK_ATTR_PORT_FLAVOUR] ||
>>> +	    !info->attrs[DEVLINK_ATTR_PORT_PCI_PF_NUMBER]) {
>>> +		NL_SET_ERR_MSG_MOD(extack, "Port flavour or PCI PF are not
>> specified");
>>> +		return -EINVAL;
>>> +	}
>>> +	new_attrs.flavour = nla_get_u16(info-
>>> attrs[DEVLINK_ATTR_PORT_FLAVOUR]);
>>> +	new_attrs.pfnum =
>>> +nla_get_u16(info->attrs[DEVLINK_ATTR_PORT_PCI_PF_NUMBER]);
>>> +
>>
>> Presuming that the device supports it, this could be used to allow creating other
>> types of ports bsides subfunctions?
>>
> This series is creating PCI PF and subfunction ports.
> Jiri's RFC [1] explained a possibility for VF representors to follow the similar scheme if device supports it.
>

Right, VFs was the most obvious point. The ability to create VFs without
needing to destroy all VFs and re-create them seems quite useful.

> I am not sure creating other port flavours are useful enough such as CPU, PHYSICAL etc.
> I do not have enough knowledge about use case for creating CPU ports, if at all it exists.
> Usually physical ports are linked to a card hardware on how many physical ports present on circuit.
> So I find it odd if a device support physical port creation, but again its my limited view at the moment.
>
Yea, I agree here too. I find that somewhat odd, but I suppose for
everything but PHYSICAL types it's not impossible.