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.
Signed-off-by: David Ventura <[email protected]>
---
.../admin-guide/kernel-parameters.txt | 4 ++++
Documentation/admin-guide/nfs/nfsroot.rst | 3 +++
net/ipv4/ipconfig.c | 23 ++++++++++++++++---
3 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index b47940577c10..b07a035642fa 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2291,6 +2291,10 @@
ip= [IP_PNP]
See Documentation/admin-guide/nfs/nfsroot.rst.
+ ip.dev_wait_ms=
+ [IP_PNP]
+ See Documentation/admin-guide/nfs/nfsroot.rst.
+
ipcmni_extend [KNL,EARLY] Extend the maximum number of unique System V
IPC identifiers from 32,768 to 16,777,216.
diff --git a/Documentation/admin-guide/nfs/nfsroot.rst b/Documentation/admin-guide/nfs/nfsroot.rst
index 135218f33394..f26f7a342af6 100644
--- a/Documentation/admin-guide/nfs/nfsroot.rst
+++ b/Documentation/admin-guide/nfs/nfsroot.rst
@@ -223,6 +223,9 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:<dns
/proc/net/ipconfig/ntp_servers to an NTP client before mounting the real
root filesystem if it is on NFS).
+ip.dev_wait_ms=<value>
+ Set the number of milliseconds to delay after opening the network device
+ which will be autoconfigured. Defaults to 10 milliseconds.
nfsrootdebug
This parameter enables debugging messages to appear in the kernel
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index c56b6fe6f0d7..cbf35163b973 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -82,8 +82,6 @@
#define IPCONFIG_DYNAMIC
#endif
-/* Define the friendly delay before and after opening net devices */
-#define CONF_POST_OPEN 10 /* After opening: 10 msecs */
/* Define the timeout for waiting for a DHCP/BOOTP/RARP reply */
#define CONF_OPEN_RETRIES 2 /* (Re)open devices twice */
@@ -101,6 +99,7 @@
/* Wait for carrier timeout default in seconds */
static unsigned int carrier_timeout = 120;
+static unsigned int dev_wait_ms = 10;
/*
* Public IP configuration
@@ -1516,7 +1515,8 @@ static int __init ip_auto_config(void)
return err;
/* Give drivers a chance to settle */
- msleep(CONF_POST_OPEN);
+ if(dev_wait_ms > 0)
+ msleep(dev_wait_ms);
/*
* If the config information is insufficient (e.g., our IP address or
@@ -1849,3 +1849,20 @@ static int __init set_carrier_timeout(char *str)
return 1;
}
__setup("carrier_timeout=", set_carrier_timeout);
+
+
+static int __init set_dev_wait_ms(char *str)
+{
+ ssize_t ret;
+
+ if (!str)
+ return 0;
+
+ ret = kstrtouint(str, 0, &dev_wait_ms);
+ if (ret)
+ return 0;
+
+ return 1;
+}
+
+__setup("ip.dev_wait_ms=", set_dev_wait_ms);
--
2.39.2
On 2/5/24 15:06, Andrew Lunn wrote:
> On Mon, Feb 05, 2024 at 12:44:40PM +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.
> Do you see this problem with multiple drivers, or just one in
> particular. To me this seems like a driver bug, and you are just
> papering over the cracks.
>
> Andrew
I don't know of any drivers that may need to wait -- I noticed
this code path being hit when building a minimal kernel that only
had a virtio network device.
At least for the virtio device, the wait is unnecessary and bloats
the time to boot a minimal kernel from 15ms to 33ms.
David
On 2/5/24 15:06, Andrew Lunn wrote:
> On Mon, Feb 05, 2024 at 12:44:40PM +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.
> Do you see this problem with multiple drivers, or just one in
> particular. To me this seems like a driver bug, and you are just
> papering over the cracks.
>
> Andrew
I haven't seen any problems -- I assumed that some drivers need to wait,
given
On Mon, Feb 05, 2024 at 12:44:40PM +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.
Do you see this problem with multiple drivers, or just one in
particular. To me this seems like a driver bug, and you are just
papering over the cracks.
Andrew
On Mon, Feb 05, 2024 at 03:31:38PM +0100, David wrote:
> On 2/5/24 15:06, Andrew Lunn wrote:
> > On Mon, Feb 05, 2024 at 12:44:40PM +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.
> > Do you see this problem with multiple drivers, or just one in
> > particular. To me this seems like a driver bug, and you are just
> > papering over the cracks.
> >
> > Andrew
> I don't know of any drivers that may need to wait -- I noticed
> this code path being hit when building a minimal kernel that only
> had a virtio network device.
> At least for the virtio device, the wait is unnecessary and bloats
> the time to boot a minimal kernel from 15ms to 33ms.
Looking at the code, a delay has been here a long time, since before
git. However, 2011 the delay was changes from 1 second to 10ms. There
was a discussion about this at the time:
https://lore.kernel.org/netdev/[email protected]/t/
It was said that ARP and DHCP retries should recover any system where
the first transmit/receive gets lost with the change from 1s to 10ms.
Maybe after 12 years, its time to try a default of 0ms? I would
suggest that is a second patch, which is easy to revert if it all goes
horribly wrong.
Andrew