netdev - Re: KSZ9477 HSR Offloading

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: <0501b135-8a25-4461-ad3c-9f322cdccb38@lunn.ch>
Date: Fri, 15 Aug 2025 00:55:16 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Frieder Schrempf <frieder.schrempf@...tron.de>
Cc: Woojung.Huh@...rochip.com, kuba@...nel.org, lukma@...x.de,
	netdev@...r.kernel.org, Tristram.Ha@...rochip.com
Subject: Re: KSZ9477 HSR Offloading

On Wed, Aug 13, 2025 at 03:43:14PM +0200, Frieder Schrempf wrote:
> Am 04.02.25 um 15:55 schrieb Woojung.Huh@...rochip.com:
> > Hi Jakub,
> > 
> >> -----Original Message-----
> >> From: Jakub Kicinski <kuba@...nel.org>
> >> Sent: Monday, February 3, 2025 6:04 PM
> >> To: Woojung Huh - C21699 <Woojung.Huh@...rochip.com>
> >> Cc: frieder.schrempf@...tron.de; lukma@...x.de; andrew@...n.ch;
> >> netdev@...r.kernel.org; Tristram Ha - C24268 <Tristram.Ha@...rochip.com>
> >> Subject: Re: KSZ9477 HSR Offloading
> >>
> >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> >> content is safe
> >>
> >> On Mon, 3 Feb 2025 14:58:12 +0000 Woojung.Huh@...rochip.com wrote:
> >>> Hi Lukasz & Frieder,
> >>>
> >>> Oops! My bad. I confused that Lukasz was filed a case originally. Monday
> >> brain-freeze. :(
> >>>
> >>> Yes, it is not a public link and per-user case. So, only Frieder can see
> >> it.
> >>> It may be able for you when Frieder adds you as a team. (Not tested
> >> personally though)
> >>
> >> Woojung Huh, please make sure the mailing list is informed about
> >> the outcomes. Taking discussion off list to a closed ticketing
> >> system is against community rules. See below, thanks.
> >>
> >> Quoting documentation:
> >>
> >>   Open development
> >>   ----------------
> >>
> >>   Discussions about user reported issues, and development of new code
> >>   should be conducted in a manner typical for the larger subsystem.
> >>   It is common for development within a single company to be conducted
> >>   behind closed doors. However, development and discussions initiated
> >>   by community members must not be redirected from public to closed forums
> >>   or to private email conversations. Reasonable exceptions to this guidance
> >>   include discussions about security related issues.
> >>
> >> See: https://www.kernel.org/doc/html/next/maintainer/feature-and-driver-maintainers.html#open-development
> > 
> > Learn new thing today. Didn't know this. Definitely I will share it
> > when this work is done. My intention was for easier work for request than
> The HW forwarding between HSR ports is configured in ksz9477_hsr_join()
> at the time of creating the HSR interface by calling
> ksz9477_cfg_port_member().
> 
> In my case I enabled the ports **after** that which caused the
> forwarding to be disabled again as ksz9477_cfg_port_member() gets called
> with the default configuration.
> 
> If I reorder my commands everything seems to work fine even with
> NETIF_F_HW_HSR_FWD enabled.
> 
> I wonder if the kernel should handle this case and prevent the
> forwarding configuration to be disabled if HSR is configured? I'll have
> a look if I can come up with a patch for this.

If you don't offload it, but do it in software, does the order matter?

As a user, i should not need to care if offload is used or not. It
should be transparent. Which means any order that works with pure
software should also work with offloading. At least, it should not
break. If it fails to offload, and uses software, that is fine. Not
optimal, but O.K.

	Andrew