[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<DB9PR04MB92591B3DA0F1CB9CBDE83C24F05EA@DB9PR04MB9259.eurprd04.prod.outlook.com>
Date: Thu, 24 Jul 2025 10:54:51 +0000
From: Xiaoliang Yang <xiaoliang.yang_1@....com>
To: Lukasz Majewski <lukma@...x.de>
CC: "davem@...emloft.net" <davem@...emloft.net>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "kuba@...nel.org" <kuba@...nel.org>,
"n.zhandarovich@...tech.ru" <n.zhandarovich@...tech.ru>,
"edumazet@...gle.com" <edumazet@...gle.com>, "pabeni@...hat.com"
<pabeni@...hat.com>, "horms@...nel.org" <horms@...nel.org>,
"m-karicheri2@...com" <m-karicheri2@...com>, Vladimir Oltean
<vladimir.oltean@....com>
Subject: RE: [EXT] Re: [RFC PATCH net-next] net: hsr: create an API to get hsr
port type
Hi Lukasz,
>
> Hi Xiaoliang,
>
> > If a switch device has HSR hardware ability and HSR configuration
> > offload to hardware. The device driver needs to get the HSR port type
> > when joining the port to HSR. Different port types require different
> > settings for the hardware, like HSR_PT_SLAVE_A, HSR_PT_SLAVE_B, and
> > HSR_PT_INTERLINK. Create the API hsr_get_port_type() and export it.
> >
>
> Could you describe the use case in more detail - as pointed out by Vladimir?
>
> In my use case - when I use the KSZ9477 switch I just provide correct arguments
> for the iproute2 configuration:
>
> # Configuration - RedBox (EVB-KSZ9477):
> if link set lan1 down;ip link set lan2 down ip link add name hsr0 type hsr slave1
> lan1 slave2 lan2 supervision 45
> version 1
> ip link add name hsr1 type hsr slave1 lan4 slave2 lan5 interlink lan3
> supervision 45 version 1
> ip link set lan4 up;ip link set lan5 up
> ip link set lan3 up
> ip addr add 192.168.0.11/24 dev hsr1
> ip link set hsr1 up
>
> # Configuration - DAN-H (EVB-KSZ9477):
> ip link set lan1 down;ip link set lan2 down ip link add name hsr0 type hsr slave1
> lan1 slave2 lan2 supervision 45
> version 1
> ip link add name hsr1 type hsr slave1 lan4 slave2 lan5 supervision 45
> version 1
> ip link set lan4 up;ip link set lan5 up
> ip addr add 192.168.0.12/24 dev hsr1
> ip link set hsr1 up
>
> More info (also regarding HSR testing with QEMU) can be found from:
> https://lpc.events/event/18/contributions/1969/attachments/1456/3092/lpc-
> 2024-HSR-v1.0-e26d140f6845e94afea.pdf
>
>
> As fair as I remember - the Node Table can be read from debugfs.
>
> However, such approach has been regarded as obsolete - by the community.
>
> In the future development plans there was the idea to use netlink (or iproute
> separate program) to get the data now available in debugfs and extend it to also
> print REDBOX node info (not only DANH).
>
I need to offload the NETIF_F_HW_HSR_TAG_INS and NETIF_F_HW_HSR_TAG_RM
to hardware. The hardware needs to know which ports are slave ports, which is
interlink port.
Hardware remove HSR tag on interlink port if it is egress port, keep the HSR tag
on HSR slave ports. The frames from ring network are removed HSR tag and
forwarded to interlink port in hardware, not received in HSR stack.
Thanks,
Xiaoliang
Powered by blists - more mailing lists