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] [day] [month] [year] [list]
Message-ID: <20240702092413.GB598357@kernel.org>
Date: Tue, 2 Jul 2024 10:24:13 +0100
From: Simon Horman <horms@...nel.org>
To: Roger Quadros <rogerq@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Siddharth Vadapalli <s-vadapalli@...com>,
	Julien Panis <jpanis@...libre.com>, Andrew Lunn <andrew@...n.ch>,
	srk@...com, vigneshr@...com, danishanwar@...com,
	pekka Varis <p-varis@...com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org
Subject: Re: [PATCH net-next v2 6/7] net: ethernet: ti: cpsw_ale: add helper
 to setup classifier defaults

On Mon, Jul 01, 2024 at 01:32:08PM +0300, Roger Quadros wrote:
> 
> On 01/07/2024 10:35, Simon Horman wrote:
> > On Fri, Jun 28, 2024 at 03:01:55PM +0300, Roger Quadros wrote:
> >> Default behaviour is to have 8 classifiers to map 8 DSCP/PCP
> >> priorities to N receive threads (flows). N depends on number of
> >> RX channels enabled for the port.
> >>
> >> Signed-off-by: Roger Quadros <rogerq@...nel.org>
> >> ---
> >>  drivers/net/ethernet/ti/cpsw_ale.c | 57 ++++++++++++++++++++++++++++++++++++++
> >>  drivers/net/ethernet/ti/cpsw_ale.h |  1 +
> >>  2 files changed, 58 insertions(+)
> >>
> >> diff --git a/drivers/net/ethernet/ti/cpsw_ale.c b/drivers/net/ethernet/ti/cpsw_ale.c
> >> index 75a17184d34c..51da527388df 100644
> >> --- a/drivers/net/ethernet/ti/cpsw_ale.c
> >> +++ b/drivers/net/ethernet/ti/cpsw_ale.c
> >> @@ -1650,3 +1650,60 @@ static void cpsw_ale_policer_thread_idx_enable(struct cpsw_ale *ale, u32 idx,
> >>  	regmap_field_write(ale->fields[ALE_THREAD_VALUE], thread_id);
> >>  	regmap_field_write(ale->fields[ALE_THREAD_ENABLE], enable ? 1 : 0);
> >>  }
> >> +
> >> +/* Disable all policer entries and thread mappings */
> >> +static void cpsw_ale_policer_reset(struct cpsw_ale *ale)
> >> +{
> >> +	int i;
> >> +
> >> +	for (i = 0; i < ale->params.num_policers ; i++) {
> >> +		cpsw_ale_policer_read_idx(ale, i);
> >> +		regmap_field_write(ale->fields[POL_PORT_MEN], 0);
> >> +		regmap_field_write(ale->fields[POL_PRI_MEN], 0);
> >> +		regmap_field_write(ale->fields[POL_OUI_MEN], 0);
> >> +		regmap_field_write(ale->fields[POL_DST_MEN], 0);
> >> +		regmap_field_write(ale->fields[POL_SRC_MEN], 0);
> >> +		regmap_field_write(ale->fields[POL_OVLAN_MEN], 0);
> >> +		regmap_field_write(ale->fields[POL_IVLAN_MEN], 0);
> >> +		regmap_field_write(ale->fields[POL_ETHERTYPE_MEN], 0);
> >> +		regmap_field_write(ale->fields[POL_IPSRC_MEN], 0);
> >> +		regmap_field_write(ale->fields[POL_IPDST_MEN], 0);
> >> +		regmap_field_write(ale->fields[POL_EN], 0);
> >> +		regmap_field_write(ale->fields[POL_RED_DROP_EN], 0);
> >> +		regmap_field_write(ale->fields[POL_YELLOW_DROP_EN], 0);
> >> +		regmap_field_write(ale->fields[POL_PRIORITY_THREAD_EN], 0);
> >> +
> >> +		cpsw_ale_policer_thread_idx_enable(ale, i, 0, 0);
> >> +	}
> >> +}
> >> +
> >> +/* Default classifer is to map 8 user priorities to N receive channels */
> >> +void cpsw_ale_classifier_setup_default(struct cpsw_ale *ale, int num_rx_ch)
> >> +{
> >> +	int pri, idx;
> >> +	int pri_thread_map[8][9] = {	{ 0, 0, 0, 0, 0, 0, 0, 0, },
> >> +					{ 0, 0, 0, 0, 1, 1, 1, 1, },
> >> +					{ 0, 0, 0, 0, 1, 1, 2, 2, },
> >> +					{ 1, 0, 0, 1, 2, 2, 3, 3, },
> >> +					{ 1, 0, 0, 1, 2, 3, 4, 4, },
> >> +					{ 1, 0, 0, 2, 3, 4, 5, 5, },
> >> +					{ 1, 0, 0, 2, 3, 4, 5, 6, },
> >> +					{ 2, 0, 1, 3, 4, 5, 6, 7, } };
> > 
> > Hi Roger,
> > 
> > Perhaps it is obvious, but I'm wondering if it is appropriate
> > to add a comment explaining the layout of the table, especially
> > the latter rows where the mapping of priority to receive channel
> > seems somewhat non-trivial.
> 
> Sure. I took the table straight off from the All new switch book. [1]
> 
> Priorities 3 to 7 are straight forward. Priorities 0 to 2 are listed like so in
> decreasing order of priority
> 
> 0 (default)	Best Effort
> 2 		Spare (undefined)
> 1 (lowest)	Background
> 
> [1] Table 13-2 IEEE 802.1p Recommended Priority Mappings to Class of Service.

Thanks Roger,

I was able to correlate this with tables G-2 and G-3 of 802.1D-2004.

I do think it would be adding some sort of comment to the code
about this.

...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ