On Wed, 5 Feb 2014, Denys Vlasenko wrote: > On Tue, Feb 4, 2014 at 8:48 PM, Cristian Ionescu-Idbohrn > <[email protected]> wrote: > > The backside of this, IIRC, is that udhcpc will eat up huge chunks of > > CPU parsing "uninteresting" packets, on "heavy" loaded networks. > > udhcpc does not listen to the network after it established a lease.
As I said, it's not the wait to get a lease that is a problem but the high CPU load (parsing packets). Yes. But imagine the usecase where you get a power outage and a farm of embedded systems fight to get a lease. Also, every time a lease renew occurs CPU gets wasted parsing "uninteresting" packets. > It just sleeps, usually for hours, waiting for 1/2 of the lease time > to expire. No network sockets are open during that time: > > # ls -l /proc/1412/fd > total 0 > lr-x------ 1 root root 64 Feb 5 15:08 0 -> /dev/null > l-wx------ 1 root root 64 Feb 5 15:08 1 -> pipe:[16588] > l-wx------ 1 root root 64 Feb 5 15:08 2 -> pipe:[16588] > lr-x------ 1 root root 64 Feb 5 15:08 3 -> pipe:[22350] > l-wx------ 1 root root 64 Feb 5 15:08 4 -> pipe:[22350] > > fds 1 and 2 are stdout/err (in my case, directed to a logger), > fds 3 and 4 is the internal signal pipe. Yes. I understand that. Still, would you accept a patch that makes the BPF filter an option? Cheers, -- Cristian _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
