Re: [PATCH net-next RFC v1 1/4] net: devlink: Add support for port regions

[Vladimir Oltean <vladimir.oltean@nxp.com>]

On Sat, Sep 19, 2020 at 04:43:29PM +0200, Andrew Lunn wrote:
> Allow regions to be registered to a devlink port. The same netlink API
> is used, but the port index is provided to indicate when a region is a
> port region as opposed to a device region.
> 
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
>  include/net/devlink.h |  27 +++++
>  net/core/devlink.c    | 251 +++++++++++++++++++++++++++++++++++++-----
>  2 files changed, 252 insertions(+), 26 deletions(-)
> 
> diff --git a/net/core/devlink.c b/net/core/devlink.c
> index 045468390480..66469cdcdc1e 100644
> --- a/net/core/devlink.c
> +++ b/net/core/devlink.c
> @@ -4198,16 +4225,30 @@ static int devlink_nl_cmd_region_get_doit(struct sk_buff *skb,
>  					  struct genl_info *info)
>  {
>  	struct devlink *devlink = info->user_ptr[0];
> +	struct devlink_port *port = NULL;
>  	struct devlink_region *region;
>  	const char *region_name;
>  	struct sk_buff *msg;
> +	unsigned int index;
>  	int err;
>  
>  	if (!info->attrs[DEVLINK_ATTR_REGION_NAME])
>  		return -EINVAL;
>  
> +	if (info->attrs[DEVLINK_ATTR_PORT_INDEX]) {
> +		index = nla_get_u32(info->attrs[DEVLINK_ATTR_PORT_INDEX]);
> +
> +		port = devlink_port_get_by_index(devlink, index);
> +		if (!port)
> +			return -ENODEV;
> +	}
> +
>  	region_name = nla_data(info->attrs[DEVLINK_ATTR_REGION_NAME]);
> -	region = devlink_region_get_by_name(devlink, region_name);
> +	if (port)
> +		region = devlink_port_region_get_by_name(port, region_name);
> +	else
> +		region = devlink_region_get_by_name(devlink, region_name);
> +

This looks like a simple enough solution, but am I right that old
kernels, which ignore this new DEVLINK_ATTR_PORT_INDEX netlink
attribute, will consequently interpret any devlink command for a port as
being for a global region? Sure, in the end, that kernel will probably
fail anyway, due to the region name mismatch. And at the moment there
isn't any driver that registers a global and a port region with the same
name. But when that will happen, the user space tools of the future will
trigger incorrect behavior into the kernel of today, instead of it
reporting an unsupported operation as it should. Or am I
misunderstanding?

>  	if (!region)
>  		return -EINVAL;
>  

Thanks,
-Vladimir