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
| ||
|
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.
Powered by blists - more mailing lists