From: Guillaume Nault <gnault@redhat.com>
To: Roger Quadros <rogerq@kernel.org>
Cc: Siddharth Vadapalli <s-vadapalli@ti.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
linux-omap@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, srk@ti.com,
Pekka Varis <p-varis@ti.com>
Subject: Re: [PATCH net-next v3 2/2] net: ethernet: ti: am65-cpsw: enable DSCP to priority map for RX
Date: Thu, 14 Nov 2024 01:16:11 +0100 [thread overview]
Message-ID: <ZzVBS1zXIy31pnaf@debian> (raw)
In-Reply-To: <20241109-am65-cpsw-multi-rx-dscp-v3-2-1cfb76928490@kernel.org>
On Sat, Nov 09, 2024 at 01:00:08PM +0200, Roger Quadros wrote:
> AM65 CPSW hardware can map the 6-bit DSCP/TOS field to
> appropriate priority queue via DSCP to Priority mapping registers
> (CPSW_PN_RX_PRI_MAP_REG).
>
> We use the upper 3 bits of the DSCP field that indicate IP Precedence
> to map traffic to 8 priority queues.
>
> Signed-off-by: Roger Quadros <rogerq@kernel.org>
> ---
> drivers/net/ethernet/ti/am65-cpsw-nuss.c | 54 ++++++++++++++++++++++++++++++++
> 1 file changed, 54 insertions(+)
>
> diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> index 0520e9f4bea7..fab35e6aac7f 100644
> --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> @@ -71,6 +71,8 @@
> #define AM65_CPSW_PORT_REG_RX_PRI_MAP 0x020
> #define AM65_CPSW_PORT_REG_RX_MAXLEN 0x024
>
> +#define AM65_CPSW_PORTN_REG_CTL 0x004
> +#define AM65_CPSW_PORTN_REG_DSCP_MAP 0x120
> #define AM65_CPSW_PORTN_REG_SA_L 0x308
> #define AM65_CPSW_PORTN_REG_SA_H 0x30c
> #define AM65_CPSW_PORTN_REG_TS_CTL 0x310
> @@ -94,6 +96,10 @@
> /* AM65_CPSW_PORT_REG_PRI_CTL */
> #define AM65_CPSW_PORT_REG_PRI_CTL_RX_PTYPE_RROBIN BIT(8)
>
> +/* AM65_CPSW_PN_REG_CTL */
> +#define AM65_CPSW_PN_REG_CTL_DSCP_IPV4_EN BIT(1)
> +#define AM65_CPSW_PN_REG_CTL_DSCP_IPV6_EN BIT(2)
> +
> /* AM65_CPSW_PN_TS_CTL register fields */
> #define AM65_CPSW_PN_TS_CTL_TX_ANX_F_EN BIT(4)
> #define AM65_CPSW_PN_TS_CTL_TX_VLAN_LT1_EN BIT(5)
> @@ -176,6 +182,53 @@ static void am65_cpsw_port_set_sl_mac(struct am65_cpsw_port *slave,
> writel(mac_lo, slave->port_base + AM65_CPSW_PORTN_REG_SA_L);
> }
>
> +#define AM65_CPSW_DSCP_MAX GENMASK(5, 0)
> +#define AM65_CPSW_PRI_MAX GENMASK(2, 0)
> +#define AM65_CPSW_DSCP_PRI_PER_REG 8
> +#define AM65_CPSW_DSCP_PRI_SIZE 4 /* in bits */
> +static int am65_cpsw_port_set_dscp_map(struct am65_cpsw_port *slave, u8 dscp, u8 pri)
> +{
> + int reg_ofs;
> + int bit_ofs;
> + u32 val;
> +
> + if (dscp > AM65_CPSW_DSCP_MAX)
> + return -EINVAL;
> +
> + if (pri > AM65_CPSW_PRI_MAX)
> + return -EINVAL;
> +
> + /* 32-bit register offset to this dscp */
> + reg_ofs = (dscp / AM65_CPSW_DSCP_PRI_PER_REG) * 4;
> + /* bit field offset to this dscp */
> + bit_ofs = AM65_CPSW_DSCP_PRI_SIZE * (dscp % AM65_CPSW_DSCP_PRI_PER_REG);
> +
> + val = readl(slave->port_base + AM65_CPSW_PORTN_REG_DSCP_MAP + reg_ofs);
> + val &= ~(AM65_CPSW_PRI_MAX << bit_ofs); /* clear */
> + val |= pri << bit_ofs; /* set */
> + writel(val, slave->port_base + AM65_CPSW_PORTN_REG_DSCP_MAP + reg_ofs);
> +
> + return 0;
> +}
> +
> +static void am65_cpsw_port_enable_dscp_map(struct am65_cpsw_port *slave)
> +{
> + int dscp, pri;
> + u32 val;
> +
> + /* Map IP Precedence field to Priority */
> + for (dscp = 0; dscp <= AM65_CPSW_DSCP_MAX; dscp++) {
> + pri = dscp >> 3; /* Extract IP Precedence */
> + am65_cpsw_port_set_dscp_map(slave, dscp, pri);
> + }
> +
> + /* enable port IPV4 and IPV6 DSCP for this port */
> + val = readl(slave->port_base + AM65_CPSW_PORTN_REG_CTL);
> + val |= AM65_CPSW_PN_REG_CTL_DSCP_IPV4_EN |
> + AM65_CPSW_PN_REG_CTL_DSCP_IPV6_EN;
> + writel(val, slave->port_base + AM65_CPSW_PORTN_REG_CTL);
> +}
It seems that this hardware is capable of mapping all possible DSCP
values. Then why restricting the mapping to the 3 high order bits only?
According to RFC 8325 section 2.3, this seem to be a common practice,
which this RFC considers a problem:
https://datatracker.ietf.org/doc/html/rfc8325#section-2.3
I know this RFC is about 802.11, not 802.1p, but as far as I know, the
user priority (UP) are the same for both, so that shouldn't make a
difference.
So what about following the IETF mapping found in section 4.3?
https://datatracker.ietf.org/doc/html/rfc8325#section-4.3
> static void am65_cpsw_sl_ctl_reset(struct am65_cpsw_port *port)
> {
> cpsw_sl_reset(port->slave.mac_sl, 100);
> @@ -921,6 +974,7 @@ static int am65_cpsw_nuss_ndo_slave_open(struct net_device *ndev)
> common->usage_count++;
>
> am65_cpsw_port_set_sl_mac(port, ndev->dev_addr);
> + am65_cpsw_port_enable_dscp_map(port);
>
> if (common->is_emac_mode)
> am65_cpsw_init_port_emac_ale(port);
>
> --
> 2.34.1
>
>
next prev parent reply other threads:[~2024-11-14 0:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-09 11:00 [PATCH net-next v3 0/2] net: ethernet: ti: am65-cpsw: enable DSCP to priority map for RX Roger Quadros
2024-11-09 11:00 ` [PATCH net-next v3 1/2] net: ethernet: ti: am65-cpsw: update pri_thread_map as per IEEE802.1Q-2014 Roger Quadros
2024-11-09 11:00 ` [PATCH net-next v3 2/2] net: ethernet: ti: am65-cpsw: enable DSCP to priority map for RX Roger Quadros
2024-11-11 5:28 ` Siddharth Vadapalli
2024-11-14 0:16 ` Guillaume Nault [this message]
2024-11-14 9:41 ` Roger Quadros
2024-11-14 10:12 ` Roger Quadros
2024-11-14 12:02 ` Guillaume Nault
2024-11-14 12:47 ` Roger Quadros
2024-11-14 13:17 ` Guillaume Nault
2024-11-14 12:13 ` Guillaume Nault
2024-11-12 14:08 ` [PATCH net-next v3 0/2] " Simon Horman
2024-11-14 0:19 ` Guillaume Nault
2024-11-14 8:55 ` Roger Quadros
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZzVBS1zXIy31pnaf@debian \
--to=gnault@redhat.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=p-varis@ti.com \
--cc=pabeni@redhat.com \
--cc=rogerq@kernel.org \
--cc=s-vadapalli@ti.com \
--cc=srk@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.