netdev - Re: [net-next v5 03/15] devlink: Introduce PCI SF port flavour and port attribute

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]

Message-ID: <20201215152740.0b3ed376@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
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?