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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 18 Sep 2020 16:06:59 -0700
From:   Jacob Keller <jacob.e.keller@...el.com>
To:     Parav Pandit <parav@...dia.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:     Jiri Pirko <jiri@...dia.com>
Subject: Re: [PATCH net-next v2 2/8] devlink: Support add and delete devlink
 port



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