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] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 15 Dec 2020 15:27:40 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Saeed Mahameed <saeed@...nel.org>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jason Gunthorpe <jgg@...dia.com>,
        Leon Romanovsky <leonro@...dia.com>, netdev@...r.kernel.org,
        linux-rdma@...r.kernel.org, David Ahern <dsahern@...nel.org>,
        Jacob Keller <jacob.e.keller@...el.com>,
        Sridhar Samudrala <sridhar.samudrala@...el.com>,
        david.m.ertman@...el.com, dan.j.williams@...el.com,
        kiran.patil@...el.com, gregkh@...uxfoundation.org,
        Parav Pandit <parav@...dia.com>, Jiri Pirko <jiri@...dia.com>,
        Vu Pham <vuhuong@...dia.com>,
        Saeed Mahameed <saeedm@...dia.com>
Subject: Re: [net-next v5 03/15] devlink: Introduce PCI SF port flavour and
 port attribute

On Tue, 15 Dec 2020 01:03:46 -0800 Saeed Mahameed wrote:
> + *	devlink_port_attrs_pci_sf_set - Set PCI SF port attributes
> + *
> + *	@devlink_port: devlink port
> + *	@controller: associated controller number for the devlink port instance
> + *	@pf: associated PF for the devlink port instance
> + *	@sf: associated SF of a PF for the devlink port instance
> + *	@external: indicates if the port is for an external controller
> + */
> +void devlink_port_attrs_pci_sf_set(struct devlink_port *devlink_port, u32 controller,
> +				   u16 pf, u32 sf, bool external)
> +{
> +	struct devlink_port_attrs *attrs = &devlink_port->attrs;
> +	int ret;
> +
> +	if (WARN_ON(devlink_port->registered))
> +		return;
> +	ret = __devlink_port_attrs_set(devlink_port, DEVLINK_PORT_FLAVOUR_PCI_SF);
> +	if (ret)
> +		return;
> +	attrs->pci_sf.controller = controller;
> +	attrs->pci_sf.pf = pf;
> +	attrs->pci_sf.sf = sf;
> +	attrs->pci_sf.external = external;
> +}
> +EXPORT_SYMBOL_GPL(devlink_port_attrs_pci_sf_set);

So subfunctions don't have a VF id but they may have a controller?

Can you tell us more about the use cases and deployment models you're
intending to support? Let's not add attributes and info which will go
unused.

How are SFs supposed to be used with SmartNICs? Are you assuming single
domain of control? It seems that the way the industry is moving the
major use case for SmartNICs is bare metal.

I always assumed nested eswitches when thinking about SmartNICs, what
are you intending to do?

What are your plans for enabling this feature in user space project?

Powered by blists - more mailing lists