[net-next,2/7] net: dsa: Add devlink regions support to DSA

Allow DSA drivers to make use of devlink regions, via simple wrappers.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 include/net/dsa.h |  6 ++++++
 net/dsa/dsa.c     | 16 ++++++++++++++++
 2 files changed, 22 insertions(+)

On Sun, Aug 16, 2020 at 09:43:11PM +0200, Andrew Lunn wrote:
> Allow DSA drivers to make use of devlink regions, via simple wrappers.
> 
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
>  include/net/dsa.h |  6 ++++++
>  net/dsa/dsa.c     | 16 ++++++++++++++++
>  2 files changed, 22 insertions(+)
> 
> diff --git a/include/net/dsa.h b/include/net/dsa.h
> index 63ff6f717307..8963440ec7f8 100644
> --- a/include/net/dsa.h
> +++ b/include/net/dsa.h
> @@ -660,6 +660,12 @@ void dsa_devlink_resource_occ_get_register(struct dsa_switch *ds,
>  					   void *occ_get_priv);
>  void dsa_devlink_resource_occ_get_unregister(struct dsa_switch *ds,
>  					     u64 resource_id);
> +struct devlink_region *
> +dsa_devlink_region_create(struct dsa_switch *ds,
> +			  const struct devlink_region_ops *ops,
> +			  u32 region_max_snapshots, u64 region_size);
> +void dsa_devlink_region_destroy(struct devlink_region *region);
> +
>  struct dsa_port *dsa_port_from_netdev(struct net_device *netdev);
>  
>  struct dsa_devlink_priv {
> diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
> index 86351da4e202..fea2efe5fe68 100644
> --- a/net/dsa/dsa.c
> +++ b/net/dsa/dsa.c
> @@ -412,6 +412,22 @@ void dsa_devlink_resource_occ_get_unregister(struct dsa_switch *ds,
>  }
>  EXPORT_SYMBOL_GPL(dsa_devlink_resource_occ_get_unregister);
>  
> +struct devlink_region *
> +dsa_devlink_region_create(struct dsa_switch *ds,
> +			  const struct devlink_region_ops *ops,
> +			  u32 region_max_snapshots, u64 region_size)
> +{
> +	return devlink_region_create(ds->devlink, ops, region_max_snapshots,
> +				     region_size);
> +}
> +EXPORT_SYMBOL_GPL(dsa_devlink_region_create);
> +
> +void dsa_devlink_region_destroy(struct devlink_region *region)
> +{
> +	devlink_region_destroy(region);
> +}
> +EXPORT_SYMBOL_GPL(dsa_devlink_region_destroy);
> +
>  struct dsa_port *dsa_port_from_netdev(struct net_device *netdev)
>  {
>  	if (!netdev || !dsa_slave_dev_check(netdev))
> -- 
> 2.28.0
> 

Could we perhaps open-code these from the drivers themselves? There's
hardly any added value in DSA providing a "helper" for creation of
devlink resources (regions, shared buffers, etc).

Take the ocelot/felix driver for example. It is a DSA driver whose core
functionality is provided by drivers/net/ethernet/mscc/ocelot*.c, which
is non-DSA code. If it were to implement devlink regions, presumably
that code would live in drivers/net/ethernet/mscc/ and not in
drivers/net/dsa/.

Thanks,
-Vladimir

> Could we perhaps open-code these from the drivers themselves? There's
> hardly any added value in DSA providing a "helper" for creation of
> devlink resources (regions, shared buffers, etc).
 
It is something i considered. But we already have devlink wrappers. It
would be odd to have some parts of devlink wrapped and other parts
not.

The wrapping of phys is also causing Russell King problems. Both
phylink and devlink structures are mostly hidden away in the DSA core,
but do leak a bit into the drivers.

If we do change to open coding, would we remove the existing wrappers
as well?

> Take the ocelot/felix driver for example.

ocelot/felix is just plain odd. We have to do a balancing act for
it. We don't want to take stuff out of the core just for this one odd
switch, at the detriment for other normal DSA drivers.

	Andrew

On Mon, Aug 17, 2020 at 12:06:32AM +0200, Andrew Lunn wrote:
> > Could we perhaps open-code these from the drivers themselves? There's
> > hardly any added value in DSA providing a "helper" for creation of
> > devlink resources (regions, shared buffers, etc).
>
> If we do change to open coding, would we remove the existing wrappers
> as well?
> 

Maybe?
I reckon one of the main reasons why DSA hides struct net_device is to
present a unified API for the ports that don't have one.
But with devlink we don't have that problem.

> > Take the ocelot/felix driver for example.
> 
> ocelot/felix is just plain odd. We have to do a balancing act for
> it. We don't want to take stuff out of the core just for this one odd
> switch, at the detriment for other normal DSA drivers.
> 

Yes, the ocelot/felix driver _is_ odd, but in my defence it's only as
odd as the hardware was integrated.
On the other hand, the model you're proposing would be forcing me to
register devlink regions in one way for felix DSA, and in another way
for ocelot switchdev. Or could I just ignore the helper, and call
devlink directly, even if there's a helper in place?

Thanks,
-Vladimir