[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3cecf4425b0e6f38646e25e40fd8f0fd@kapio-technology.com>
Date: Thu, 02 Feb 2023 17:19:07 +0100
From: netdev@...io-technology.com
To: Ido Schimmel <idosch@...sch.org>
Cc: davem@...emloft.net, kuba@...nel.org, netdev@...r.kernel.org,
Florian Fainelli <f.fainelli@...il.com>,
Andrew Lunn <andrew@...n.ch>,
Vladimir Oltean <olteanv@...il.com>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>,
Kurt Kanzenbach <kurt@...utronix.de>,
Hauke Mehrtens <hauke@...ke-m.de>,
Woojung Huh <woojung.huh@...rochip.com>,
"maintainer:MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER"
<UNGLinuxDriver@...rochip.com>, Sean Wang <sean.wang@...iatek.com>,
Landen Chao <Landen.Chao@...iatek.com>,
DENG Qingfang <dqfext@...il.com>,
Matthias Brugger <matthias.bgg@...il.com>,
Claudiu Manoil <claudiu.manoil@....com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Clément Léger
<clement.leger@...tlin.com>, Jiri Pirko <jiri@...nulli.us>,
Ivan Vecera <ivecera@...hat.com>,
Roopa Prabhu <roopa@...dia.com>,
Nikolay Aleksandrov <razor@...ckwall.org>,
Russell King <linux@...linux.org.uk>,
Christian Marangi <ansuelsmth@...il.com>,
open list <linux-kernel@...r.kernel.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-arm-kernel@...ts.infradead.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@...ts.infradead.org>,
"open list:RENESAS RZ/N1 A5PSW SWITCH DRIVER"
<linux-renesas-soc@...r.kernel.org>,
"moderated list:ETHERNET BRIDGE" <bridge@...ts.linux-foundation.org>
Subject: Re: [PATCH net-next 0/5] ATU and FDB synchronization on locked ports
On 2023-02-02 16:43, Ido Schimmel wrote:
> On Thu, Feb 02, 2023 at 08:37:08AM +0100, netdev@...io-technology.com
> wrote:
>> On 2023-01-31 20:25, Ido Schimmel wrote:
>> >
>> > Will try to review tomorrow, but it looks like this set is missing
>> > selftests. What about extending bridge_locked_port.sh?
>>
>> I knew you would take this up. :-)
>> But I am not sure that it's so easy to have selftests here as it is
>> timing
>> based and it would take the 5+ minutes just waiting to test in the
>> stadard
>> case, and there is opnly support for mv88e6xxx driver with this patch
>> set.
>
> The ageing time is configurable: See commit 081197591769 ("selftests:
> net: bridge: Parameterize ageing timeout"). Please add test cases in
> the
> next version.
When I was looking at configuring the ageing time last time, my finding
was that the ageing time could not be set very low as there was some
part in the DSA layer etc, and confusion wrt units. I think the minimum
secured was like around 2 min. (not validated), which is not that much
of an improvement for fast testing. If you know what would be a good low
timeout to set, I would like to know.
Powered by blists - more mailing lists