[PATCH 0/3]

[PATCH 0/3]

[dmitry.krivoschekov]

Hi,

this patch series adds some flexibility to ip_auto_config() function.
Currently the function assumes that 500 msec delay before opening
a network device is enough, but it's not true for some h/w configurations,
e.g. if you're using a USB network device. 
In my case it may take up to 2 seconds before the device gets available 
for opening.

[PATCH 1/3] ipconfig: use same time units for CONF_{PRE,POST}_OPEN delays
	this is just a small cleanup

[PATCH 2/3] ipconfig: add 'ipwait' cmdline parameter
	I introduce a new cmdline parameter so it's possible to configure two 
	delays, before and after opening of network devices. It can be used 
	to increase default delay and it also might be useful in optimizing of
	kernel boot-up time, you can save ~1 second if you know that you h/w
	does not need that delays, 500 msec before and 1 second after.

[PATCH 3/3] ipconfig: look for a network device forever if NFS root
	As time needed for a USB net device to settle may vary from
	time to time, it's hard to predict how much msecs it would 
	take next time. If we're using such a device to mount a NFS root
	filesystem it gets critical for us as we can't proceed 
	work if a net device has not found, so we have to
	loop until a suitable device gets available.
	

Tested on TI OMAP3530 Beagle board.


Regards,
Dmitry

[PATCH 1/3] ipconfig: use same time units for CONF_{PRE,POST}_OPEN delays

[dmitry.krivoschekov]

From: Dmitry Krivoschekov <dkrivoschekov@ru.mvista.com>

It's confusing that the delay before opening is measured in msecs
while after opening the delay is in seconds. Lets use the same
time units for both.

Signed-off-by: Dmitry Krivoschekov <dkrivoschekov@ru.mvista.com>
---
 net/ipv4/ipconfig.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index da134aa..4c6e38f 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -87,7 +87,7 @@
 
 /* Define the friendly delay before and after opening net devices */
 #define CONF_PRE_OPEN		500	/* Before opening: 1/2 second */
-#define CONF_POST_OPEN		1	/* After opening: 1 second */
+#define CONF_POST_OPEN		1000	/* After opening: 1 second */
 
 /* Define the timeout for waiting for a DHCP/BOOTP/RARP reply */
 #define CONF_OPEN_RETRIES 	2	/* (Re)open devices twice */
@@ -1291,7 +1291,7 @@ static int __init ip_auto_config(void)
 		return -1;
 
 	/* Give drivers a chance to settle */
-	ssleep(CONF_POST_OPEN);
+	msleep(CONF_POST_OPEN);
 
 	/*
 	 * If the config information is insufficient (e.g., our IP address or
-- 
1.6.1.2.MVISTA.5.ga9f3b

[PATCH 2/3] ipconfig: add 'ipwait' cmdline parameter

[dmitry.krivoschekov]

From: Dmitry Krivoschekov <dkrivoschekov@ru.mvista.com>

Adding a cmdline parameter so it's possible to change the delay
before and after opening a network device, e.g. "ipwait=300,700"
sets a delay for 300 and 700 msec before and after opening respectively.

Signed-off-by: Dmitry Krivoschekov <dkrivoschekov@ru.mvista.com>
---
 Documentation/filesystems/nfsroot.txt |   11 +++++++++++
 net/ipv4/ipconfig.c                   |   29 ++++++++++++++++++++++++++---
 2 files changed, 37 insertions(+), 3 deletions(-)

diff --git a/Documentation/filesystems/nfsroot.txt b/Documentation/filesystems/nfsroot.txt
index 68baddf..9b05025 100644
--- a/Documentation/filesystems/nfsroot.txt
+++ b/Documentation/filesystems/nfsroot.txt
@@ -156,8 +156,19 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
 
                 Default: any
 
+ipwait=<delay-pre>,<delay-post>
 
+  This parameter allows you to change a pause before and after opening of
+  a network device. It is useful if you want to optimize boot-up time for
+  your system, or if default delays are not sufficient for your net device.
 
+  <delay-pre>	Delay (in msecs) to pause before opening a net device
+
+                Default: 500 msec
+
+  <delay-post>	Delay (in msecs) to pause after a net device has been opened
+
+                Default: 1000 msec
 
 3.) Boot Loader
     ----------
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 4c6e38f..8222466 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -85,7 +85,7 @@
 #define IPCONFIG_DYNAMIC
 #endif
 
-/* Define the friendly delay before and after opening net devices */
+/* Define the default friendly delay before and after opening net devices */
 #define CONF_PRE_OPEN		500	/* Before opening: 1/2 second */
 #define CONF_POST_OPEN		1000	/* After opening: 1 second */
 
@@ -182,6 +182,10 @@ struct ic_device {
 static struct ic_device *ic_first_dev __initdata = NULL;/* List of open device */
 static struct net_device *ic_dev __initdata = NULL;	/* Selected device */
 
+/* delay before and after opening devices */
+static unsigned long ic_wait_pre __initdata;
+static unsigned long ic_wait_post __initdata;
+
 static int __init ic_open_devs(void)
 {
 	struct ic_device *d, **last;
@@ -1283,15 +1287,22 @@ static int __init ip_auto_config(void)
 #ifdef IPCONFIG_DYNAMIC
  try_try_again:
 #endif
+
+	if (!ic_wait_pre)
+		ic_wait_pre = CONF_PRE_OPEN;
+
 	/* Give hardware a chance to settle */
-	msleep(CONF_PRE_OPEN);
+	msleep(ic_wait_pre);
 
 	/* Setup all network devices */
 	if (ic_open_devs() < 0)
 		return -1;
 
+	if (!ic_wait_post)
+		ic_wait_post = CONF_POST_OPEN;
+
 	/* Give drivers a chance to settle */
-	msleep(CONF_POST_OPEN);
+	msleep(ic_wait_post);
 
 	/*
 	 * If the config information is insufficient (e.g., our IP address or
@@ -1529,6 +1540,18 @@ static int __init vendor_class_identifier_setup(char *addrs)
 	return 1;
 }
 
+static int __init ipwait_setup(char *addrs)
+{
+	char *p;
+
+	p = strsep(&addrs, ",");
+	if (strict_strtoul(p, 10, &ic_wait_pre) == 0)
+		strict_strtoul(addrs, 10, &ic_wait_post);
+
+	return 1;
+}
+
 __setup("ip=", ip_auto_config_setup);
+__setup("ipwait=", ipwait_setup);
 __setup("nfsaddrs=", nfsaddrs_config_setup);
 __setup("dhcpclass=", vendor_class_identifier_setup);
-- 
1.6.1.2.MVISTA.5.ga9f3b

[PATCH 3/3] ipconfig: look for a network device forever if NFS root

[dmitry.krivoschekov]

From: Dmitry Krivoschekov <dkrivoschekov@ru.mvista.com>

For now ip_auto_config() makes a pause before opening a network device
so the h/w can settle. It may not work well for USB network devices
as the period needed for devices to settle may vary from time to time due
to non-deterministic specifics of USB protocol itself.
The period will also depend on a certain USB configuration, e.g. whether
a USB device is sitting behind a USB hub(s) or not.

The issue gets critical when such a device is used to mount a NFS root
filesystem. Currently if ip_auto_config() can't find a network device
it gives up leaving the kernel in unusable state.

To resolve the issue the patch adds a loop waiting until a
suitable network device gets available.

Signed-off-by: Dmitry Krivoschekov <dkrivoschekov@ru.mvista.com>
---
 net/ipv4/ipconfig.c |   14 +++++++++++---
 1 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 8222466..0066424 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -1284,7 +1284,7 @@ static int __init ip_auto_config(void)
 		return 0;
 
 	DBG(("IP-Config: Entered.\n"));
-#ifdef IPCONFIG_DYNAMIC
+#if defined(IPCONFIG_DYNAMIC) || defined(CONFIG_ROOT_NFS)
  try_try_again:
 #endif
 
@@ -1295,8 +1295,16 @@ static int __init ip_auto_config(void)
 	msleep(ic_wait_pre);
 
 	/* Setup all network devices */
-	if (ic_open_devs() < 0)
-		return -1;
+	if (ic_open_devs() < 0) {
+#ifdef CONFIG_ROOT_NFS
+		if (ROOT_DEV ==  Root_NFS) {
+			printk(KERN_ERR	"IP-Config: Could not open device, "
+					"Retrying forever (NFS root)...\n");
+			goto try_try_again;
+		} else
+#endif
+			return -1;
+	}
 
 	if (!ic_wait_post)
 		ic_wait_post = CONF_POST_OPEN;
-- 
1.6.1.2.MVISTA.5.ga9f3b

Re: [PATCH 0/3]

[David Miller]

From: dmitry.krivoschekov@gmail.com
Date: Thu, 16 Apr 2009 13:37:36 +0400

> this patch series adds some flexibility to ip_auto_config() function.
> Currently the function assumes that 500 msec delay before opening
> a network device is enough, but it's not true for some h/w configurations,
> e.g. if you're using a USB network device. 
> In my case it may take up to 2 seconds before the device gets available 
> for opening.

I think this problem space would be served better by a scheme
that just worked automatically.

If the user put nfsroot= onto the kernel command line, the expectation
is that the device is expected to be there.

Therefore it is reasonable to make the ipconfig.c code do a loop
periodically retrying to open the intended network device.  And after
several seconds of iterations, fail.

Heck, it doesn't even need to do anything fancy.  After the initial
attempt, it can simply wait for the NETDEV_REGISTER notifier event.
Then it will know exactly when the device shows up.

In fact you won't need anything to implement this, simply register the
notifier and make the notifier trigger the ipconfig.c code to do a
DHCP or RARP probe or whatever when the device we're interested in
appears.

I'm not applying these patches, sorry.

Re: [PATCH 0/3] ipconfig tweaks

[Dmitry Krivoschekov]

David Miller wrote:

>From: dmitry.krivoschekov@gmail.com
>Date: Thu, 16 Apr 2009 13:37:36 +0400
>
>
>>this patch series adds some flexibility to ip_auto_config() function.
>>Currently the function assumes that 500 msec delay before opening
>>a network device is enough, but it's not true for some h/w configurations,
>>e.g. if you're using a USB network device. 
>>In my case it may take up to 2 seconds before the device gets available 
>>for opening.
>>
>
>I think this problem space would be served better by a scheme
>that just worked automatically.
>
yes, sure, and my third patch tries to add such a scheme:
http://www.spinics.net/lists/netdev/msg94723.html

while the first two patches can be considered separately:
http://www.spinics.net/lists/netdev/msg94724.html
http://www.spinics.net/lists/netdev/msg94726.html

as the patches allow you to change that pre-defined delays, i.e. you
can adjust the delays for your particular system. As I wrote it could
save about 1 second of boot-up time.

>
>If the user put nfsroot= onto the kernel command line, the expectation
>is that the device is expected to be there.
>
>
Agreed.

>Therefore it is reasonable to make the ipconfig.c code do a loop
>periodically retrying to open the intended network device.  And after
>several seconds of iterations, fail.
>

Why it should fail? What do you expect from the system to do when it fails?
It gets unusable anyways and you'll have to reboot it again. But, if it will
be infinitely looping, there is a chance it finds something suitable :).
If you're sure it won't find anything then reboot it and configure it 
properly.
In fact, DHCP code can loop infinitely (see "try_try_again" loop).

>
>Heck, it doesn't even need to do anything fancy.  After the initial
>attempt, it can simply wait for the NETDEV_REGISTER notifier event.
>Then it will know exactly when the device shows up.
>
>In fact you won't need anything to implement this, simply register the
>notifier and make the notifier trigger the ipconfig.c code to do a
>DHCP or RARP probe or whatever when the device we're interested in
>appears.
>
>
ok, I'try it

>I'm not applying these patches, sorry.
>

As I wrote above, the first two patches can be considered separately.
Why don't let users to optimize boot-up time?


Thanks,
Dmitry

Re: [PATCH 0/3] ipconfig tweaks

[David Miller]

From: Dmitry Krivoschekov <dmitry.krivoschekov@gmail.com>
Date: Fri, 17 Apr 2009 14:00:40 +0400

> Why don't let users to optimize boot-up time?

Because a generic scheme that works automatically is 1,000
times better than random kernel command line parms.

Re: [PATCH 0/3] ipconfig tweaks

[Benny Amorsen]

Dmitry Krivoschekov <dmitry.krivoschekov@gmail.com> writes:

> as the patches allow you to change that pre-defined delays, i.e. you
> can adjust the delays for your particular system. As I wrote it could
> save about 1 second of boot-up time.

Perhaps it could change the delay to be extremely short (or
non-existent?) for VLAN devices? Currently, starting 1000 VLAN devices
is very painful even without trying to add IP addresses.

Adding IP addresses is even more painful, at least with the Fedora
initscripts, but that is not a kernel issue.

The other option is to just start the devices in parallel.


/Benny