[<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