On 9/17/2020 9:25 PM, Parav Pandit wrote:
>> From: Jacob Keller <jacob.e.kel...@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.
