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 PHC
Open Source and information security mailing list archives

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

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

Date:   Sat, 19 Sep 2020 05:39:09 +0000
From:   Parav Pandit <parav@...dia.com>
To:     Jacob Keller <jacob.e.keller@...el.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



> From: Jacob Keller <jacob.e.keller@...el.com>
> Sent: Saturday, September 19, 2020 4:37 AM
> 
> 
> 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.
> 
Yes.
> > 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.
Ok.