[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <646c4248586b419fd9ca483aa13fb774d8b08195.camel@mellanox.com>
Date: Mon, 2 Mar 2020 18:48:22 +0000
From: Saeed Mahameed <saeedm@...lanox.com>
To: "kuba@...nel.org" <kuba@...nel.org>
CC: Vlad Buslov <vladbu@...lanox.com>, Jiri Pirko <jiri@...lanox.com>,
Roi Dayan <roid@...lanox.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Jianbo Liu <jianbol@...lanox.com>
Subject: Re: [net-next 08/16] net/mlx5e: Add devlink fdb_large_groups
parameter
On Fri, 2020-02-28 at 11:10 -0800, Jakub Kicinski wrote:
> On Thu, 27 Feb 2020 16:44:38 -0800 Saeed Mahameed wrote:
> > From: Jianbo Liu <jianbol@...lanox.com>
> >
> > Add a devlink parameter to control the number of large groups in a
> > autogrouped flow table. The default value is 15, and the range is
> > between 1
> > and 1024.
> >
> > The size of each large group can be calculated according to the
> > following
> > formula: size = 4M / (fdb_large_groups + 1).
> >
> > Examples:
> > - Set the number of large groups to 20.
> > $ devlink dev param set pci/0000:82:00.0 name fdb_large_groups
> > \
> > cmode driverinit value 20
> >
> > Then run devlink reload command to apply the new value.
> > $ devlink dev reload pci/0000:82:00.0
> >
> > - Read the number of large groups in flow table.
> > $ devlink dev param show pci/0000:82:00.0 name fdb_large_groups
> > pci/0000:82:00.0:
> > name fdb_large_groups type driver-specific
> > values:
> > cmode driverinit value 20
> >
> > Signed-off-by: Jianbo Liu <jianbol@...lanox.com>
> > Reviewed-by: Vlad Buslov <vladbu@...lanox.com>
> > Reviewed-by: Roi Dayan <roid@...lanox.com>
> > Acked-by: Jiri Pirko <jiri@...lanox.com>
> > Signed-off-by: Saeed Mahameed <saeedm@...lanox.com>
>
> Slicing memory up sounds like something that should be supported via
> the devlink-resource API, not by params and non-obvious calculations
> :(
Hi Jakub, you have a point, but due to to the non-triviality of the
internal mlnx driver and FW architecture of handling internal FDB table
breakdown, we preferred to go with one driver-specific parameter to
simplify the approach, instead of 3 or 4 generic params, which will not
make any sense to other vendors for now.
As always we will keep an eye on what other vendors are doing and will
try to unify with a generic set of params once other vendors show
interest of a similar thing.
Thanks,
Saeed.
Powered by blists - more mailing lists