Message-ID: <6fd57ef6-b018-4d08-9914-38d4f089d313@kontron.de>
Date: Wed, 13 Aug 2025 17:42:19 +0200
From: Frieder Schrempf <frieder.schrempf@...tron.de>
To: Łukasz Majewski <lukma@...ladev.com>
Cc: Woojung.Huh@...rochip.com, kuba@...nel.org, andrew@...n.ch,
 netdev@...r.kernel.org, Tristram.Ha@...rochip.com
Subject: Re: KSZ9477 HSR Offloading

Hi Lukasz,

Am 13.08.25 um 15:54 schrieb Łukasz Majewski:
> [Sie erhalten nicht h?ufig E-Mails von lukma@...ladev.com. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hi Frieder,
> 
>> 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 having me as an middleman for the issue.
>>
>> Here is a follow-up for this thread. I was busy elsewhere, didn't have
>> access to the hardware and failed to respond to the comments from
>> Microchip support team provided in their internal ticket system.
>>
>> As a summary, the Microchip support couldn't reproduce my issue on
>> their side and asked for further information.
>>
>> With the hardware now back on my table I was able to do some further
>> investigations and found out that this is caused by a misconfiguration
>> on my side, that doesn't get handled/prevented by the kernel.
> 
> If I remember correctly from the ticket - there was also an issue with
> the size of MTU for HSR packets.
> 
> Am I correct?

The Microchip support mentioned the following:

###
Note the default MTU of hsr0 is (1500 - 6) = 1494. When other HSR node
is used the MTU needs to match. The HSR driver code checks the MTU of
the underneath device to see if it should be lowered. Even that device
can send more than 1506 bytes the value still is fixed at 1500 and then
decreased by 6. In my opinion that should be changed to start 1506 and
then lower to 1500 if the lower device cannot send that. The RedBox
operation also will be impacted if the MTU 1494 is used as the devices
behind the Redbox all uses MTU 1500
###

So far I didn't run into any issues related to MTU, but I might stumble
upon this in the future.

> 
>>
>> 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.
>>
> 
> Thanks  for looking for this issue. I'm looking forward for your
> patches.

I came up with [1] which fixes the issue that I was seeing. I hope that
this goes into the right direction.

Thanks
Frieder

[1]
https://patchwork.kernel.org/project/netdevbpf/patch/20250813152615.856532-1-frieder@fris.de/

Powered by blists - more mailing lists