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

[Jakub Kicinski <kuba@kernel.org>]

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?