All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukasz Majewski <lukma@denx.de>
To: Frieder Schrempf <frieder.schrempf@kontron.de>
Cc: Andrew Lunn <andrew@lunn.ch>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: KSZ9477 HSR Offloading
Date: Wed, 29 Jan 2025 12:17:33 +0100	[thread overview]
Message-ID: <20250129121733.1e99f29c@wsk> (raw)
In-Reply-To: <6400e73a-b165-41a8-9fc9-e2226060a68c@kontron.de>

[-- Attachment #1: Type: text/plain, Size: 4812 bytes --]

Hi Frieder,

> On 29.01.25 8:24 AM, Frieder Schrempf wrote:
> > Hi Andrew,
> > 
> > On 28.01.25 6:51 PM, Andrew Lunn wrote:  
> >> On Tue, Jan 28, 2025 at 05:14:46PM +0100, Frieder Schrempf wrote:  
> >>> Hi,
> >>>
> >>> I'm trying out HSR support on KSZ9477 with v6.12. My setup looks
> >>> like this:
> >>>
> >>> +-------------+         +-------------+
> >>> |             |         |             |
> >>> |   Node A    |         |   Node D    |
> >>> |             |         |             |
> >>> |             |         |             |
> >>> | LAN1   LAN2 |         | LAN1   LAN2 |
> >>> +--+-------+--+         +--+------+---+
> >>>    |       |               |      |
> >>>    |       +---------------+      |
> >>>    |                              |
> >>>    |       +---------------+      |
> >>>    |       |               |      |
> >>> +--+-------+--+         +--+------+---+
> >>> | LAN1   LAN2 |         | LAN1   LAN2 |
> >>> |             |         |             |
> >>> |             |         |             |
> >>> |   Node B    |         |   Node C    |
> >>> |             |         |             |
> >>> +-------------+         +-------------+
> >>>
> >>> On each device the LAN1 and LAN2 are added as HSR slaves. Then I
> >>> try to do ping tests between each of the HSR interfaces.
> >>>
> >>> The result is that I can reach the neighboring nodes just fine,
> >>> but I can't reach the remote node that needs packages to be
> >>> forwarded through the other nodes. For example I can't ping from
> >>> node A to C.
> >>>
> >>> I've tried to disable HW offloading in the driver and then
> >>> everything starts working.
> >>>
> >>> Is this a problem with HW offloading in the KSZ driver, or am I
> >>> missing something essential?  

Thanks for looking and testing such large scale setup.

> >>
> >> How are IP addresses configured? I assume you have a bridge, LAN1
> >> and LAN2 are members of the bridge, and the IP address is on the
> >> bridge interface?  
> > 
> > I have a HSR interface on each node that covers LAN1 and LAN2 as
> > slaves and the IP addresses are on those HSR interfaces. For node A:
> > 
> > ip link add name hsr type hsr slave1 lan1 slave2 lan2 supervision 45
> > version 1
> > ip addr add 172.20.1.1/24 dev hsr
> > 
> > The other nodes have the addresses 172.20.1.2/24, 172.20.1.3/24 and
> > 172.20.1.4/24 respectively.
> > 
> > Then on node A, I'm doing:
> > 
> > ping 172.20.1.2 # neighboring node B works
> > ping 172.20.1.4 # neighboring node D works
> > ping 172.20.1.3 # remote node C works only if I disable offloading  
> 
> BTW, it's enough to disable the offloading of the forwarding for HSR
> frames to make it work.
> 
> --- a/drivers/net/dsa/microchip/ksz9477.c
> +++ b/drivers/net/dsa/microchip/ksz9477.c
> @@ -1267,7 +1267,7 @@ int ksz9477_tc_cbs_set_cinc(struct ksz_device
> *dev, int port, u32 val)
>   * Moreover, the NETIF_F_HW_HSR_FWD feature is also enabled, as HSR
> frames
>   * can be forwarded in the switch fabric between HSR ports.
>   */
> -#define KSZ9477_SUPPORTED_HSR_FEATURES (NETIF_F_HW_HSR_DUP |
> NETIF_F_HW_HSR_FWD)
> +#define KSZ9477_SUPPORTED_HSR_FEATURES (NETIF_F_HW_HSR_DUP)
> 
>  void ksz9477_hsr_join(struct dsa_switch *ds, int port, struct
> net_device *hsr)
>  {
> @@ -1279,16 +1279,6 @@ void ksz9477_hsr_join(struct dsa_switch *ds,
> int port, struct net_device *hsr)
>         /* Program which port(s) shall support HSR */
>         ksz_rmw32(dev, REG_HSR_PORT_MAP__4, BIT(port), BIT(port));
> 
> -       /* Forward frames between HSR ports (i.e. bridge together HSR
> ports) */
> -       if (dev->hsr_ports) {
> -               dsa_hsr_foreach_port(hsr_dp, ds, hsr)
> -                       hsr_ports |= BIT(hsr_dp->index);
> -
> -               hsr_ports |= BIT(dsa_upstream_port(ds, port));
> -               dsa_hsr_foreach_port(hsr_dp, ds, hsr)
> -                       ksz9477_cfg_port_member(dev, hsr_dp->index,
> hsr_ports);
> -       }
> -
>         if (!dev->hsr_ports) {
>                 /* Enable discarding of received HSR frames */
>                 ksz_read8(dev, REG_HSR_ALU_CTRL_0__1, &data);

This means that KSZ9477 forwarding is dropping frames when HW
acceleration is used (for non "neighbour" nodes).

On my setup I only had 2 KSZ9477 devel boards.

And as you wrote - the SW based one works, so extending
https://elixir.bootlin.com/linux/v6.12-rc2/source/tools/testing/selftests/net/hsr

would not help in this case.


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2025-01-29 11:17 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-28 16:14 KSZ9477 HSR Offloading Frieder Schrempf
2025-01-28 17:51 ` Andrew Lunn
2025-01-29  7:24   ` Frieder Schrempf
2025-01-29  8:03     ` Frieder Schrempf
2025-01-29 11:17       ` Lukasz Majewski [this message]
2025-01-29 11:35         ` Frieder Schrempf
2025-01-29 13:26           ` Andrew Lunn
2025-01-29 13:58           ` Lukasz Majewski
2025-01-29 17:07             ` Frieder Schrempf
2025-01-29 18:57               ` Woojung.Huh
2025-01-30  8:43                 ` Frieder Schrempf
2025-01-30 14:17                   ` Woojung.Huh
2025-02-03  9:31                     ` Lukasz Majewski
2025-02-03 14:43                       ` Woojung.Huh
2025-02-03 14:47                       ` Frieder Schrempf
2025-02-03 14:58                         ` Woojung.Huh
2025-02-03 23:04                           ` Jakub Kicinski
2025-02-04 14:55                             ` Woojung.Huh
2025-08-13 13:43                               ` Frieder Schrempf
2025-08-13 13:54                                 ` Łukasz Majewski
2025-08-13 15:42                                   ` Frieder Schrempf
2025-08-14 22:55                                 ` Andrew Lunn
2025-01-29 22:52               ` Lukasz Majewski
2025-01-30 10:19                 ` Frieder Schrempf
2025-01-30 10:36                   ` Frieder Schrempf
2025-01-30 13:39                   ` Andrew Lunn
2025-01-29 13:14       ` Andrew Lunn

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=20250129121733.1e99f29c@wsk \
    --to=lukma@denx.de \
    --cc=andrew@lunn.ch \
    --cc=frieder.schrempf@kontron.de \
    --cc=netdev@vger.kernel.org \
    /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.