[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <X/+D+2AgnOqCxb2d@lunn.ch>
Date: Thu, 14 Jan 2021 00:36:27 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Vladimir Oltean <olteanv@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
Ido Schimmel <idosch@...dia.com>,
Petr Machata <petrm@...dia.com>,
Alexander Duyck <alexander.duyck@...il.com>,
Jamal Hadi Salim <jhs@...atatu.com>,
Cong Wang <xiyou.wangcong@...il.com>,
Jiri Pirko <jiri@...dia.com>, f.fainelli@...il.com,
vivien.didelot@...il.com
Subject: Re: [RFC PATCH net-next 2/2] net: dsa: felix: offload port priority
On Wed, Jan 13, 2021 at 05:41:39PM +0200, Vladimir Oltean wrote:
> From: Vladimir Oltean <vladimir.oltean@....com>
>
> Even though we should really share the implementation with the ocelot
> switchdev driver, that one needs a little bit of rework first, since its
> struct ocelot_port_tc only supports one tc matchall action at a time,
> which at the moment is used for port policers. Whereas DSA keeps a list
> of port-based actions in struct dsa_slave_priv::mall_tc_list, so it is
> much more easily extensible. It is too tempting to add the implementation
> for the port priority directly in Felix at the moment, which is what we
> do.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
> ---
> drivers/net/dsa/ocelot/felix.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
> index 768a74dc462a..5cc42c3aaf0d 100644
> --- a/drivers/net/dsa/ocelot/felix.c
> +++ b/drivers/net/dsa/ocelot/felix.c
> @@ -739,6 +739,20 @@ static void felix_port_policer_del(struct dsa_switch *ds, int port)
> ocelot_port_policer_del(ocelot, port);
> }
>
> +static int felix_port_priority_set(struct dsa_switch *ds, int port,
> + struct dsa_mall_skbedit_tc_entry *skbedit)
> +{
> + struct ocelot *ocelot = ds->priv;
> +
> + ocelot_rmw_gix(ocelot,
> + ANA_PORT_QOS_CFG_QOS_DEFAULT_VAL(skbedit->priority),
No range check? Seems like -ERANGE or similar would help avoid
surprises when somebody asks for an unsupported priority and it gets
masked to something much lower.
Andrew
Powered by blists - more mailing lists