lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 13 Jan 2021 15:37:49 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andrew Lunn <andrew@...n.ch>, 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>, vivien.didelot@...il.com
Subject: Re: [RFC PATCH net-next 2/2] net: dsa: felix: offload port priority

On 1/13/21 3:36 PM, Andrew Lunn wrote:
> 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.

You are passing the whole dsa_mall_skbedit_tc_entry  structure here,
only to look up priority, would it make sense for now to pass
skbedit->priority as a parameter which would be matching the function
name and what it is dealing with?
-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ