[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ee37f457-3d2d-4c18-b22f-dfb315b3c078@davidv.dev>
Date: Sat, 10 Feb 2024 00:15:42 +0100
From: David <david@...idv.dev>
To: Andrew Lunn <andrew@...n.ch>, Jakub Kicinski <kuba@...nel.org>
Cc: Jonathan Corbet <corbet@....net>, "David S. Miller"
<davem@...emloft.net>, David Ahern <dsahern@...nel.org>,
Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Paul E. McKenney" <paulmck@...nel.org>, Randy Dunlap
<rdunlap@...radead.org>, Xiongwei Song <xiongwei.song@...driver.com>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>,
"open list:NETWORKING [IPv4/IPv6]" <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] net: make driver settling time configurable
On 2/9/24 23:11, Andrew Lunn wrote:
> On Fri, Feb 09, 2024 at 01:59:44PM -0800, Jakub Kicinski wrote:
>> On Thu, 8 Feb 2024 10:52:29 +0100 David Ventura wrote:
>>> During IP auto configuration, some drivers apparently need to wait a
>>> certain length of time to settle; as this is not true for all drivers,
>>> make this length of time configurable.
>> Please CC folks who gave you feedback, Andrew's is missing.
Thanks for the feedback, still learning this workflow
>>
>> Andrew, what do you think about just removing the wait?
>> Or decreasing it to 1ms?
>> It feels a little wasteful to be adding uAPI for something
>> which as you said is likely papering over ancient bugs. We'll
>> fix the bugs which are still around and the uAPI will stay
>> forever :(
> My guess is, the broken drivers are doing setup stuff after they call
> netdev_register().
>
> Reducing it to 1ms will probably continue to hide such bugs. So we
> could just go with that, and probably not see any regressions. Or we
> can decide we really do want to know about broken drivers, and just
> remove the delay.
>
> Either way, we don't need a new uAPI.
Would it make sense to move this to a build-time configuration flag?
I do not have a gut-feeling for which behaviors should be configurable
at build vs run time.
> David, is 1ms too long for you? If we do take the delay out, you are
> going to receive some of the flack from regression reports.
I've used this patch to experiment with different values, and the sleep time
behaves as described in Documentation/timers/timers-howto.rst, that is, a
call of `msleep(1)` usually delays boot time by 12~13 ms in my tests.
On top of this, I'm running this specific example on a no-smp systemm,
where I
do not believe the `msleep` achieves anything (but I'm a kernel newbie
so please
correct me if I'm wrong).
>
> Andrew
>
Powered by blists - more mailing lists