netdev - Re: [net-next-2.6 PATCH] net: fast consecutive name allocation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 13 Nov 2009 11:51:31 +0200
From:	Octavian Purdila <opurdila@...acom.com>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Subject: Re: [net-next-2.6 PATCH] net: fast consecutive name allocation

On Friday 13 November 2009 08:26:08 you wrote:
> On Fri, 13 Nov 2009 07:12:35 +0100
> 
> Eric Dumazet <eric.dumazet@...il.com> wrote:
> > Octavian Purdila a écrit :
> > > On Friday 13 November 2009 07:01:14 you wrote:
> > >> This patch speeds up the network device name allocation for the case
> > >> where a significant number of devices of the same type are created
> > >> consecutively.
> > >>
> > >> Tests performed on a PPC750 @ 800Mhz machine with per device sysctl
> > >> and sysfs entries disabled:
> > >>
> > >> Without the patch           With the patch
> > >>
> > >> real    0m 43.43s	    real    0m 0.49s
> > >> user    0m 0.00s	    user    0m 0.00s
> > >> sys     0m 43.43s	    sys     0m 0.48s
> 
> No one has give a reasonable use case for this network device name
> explosion, what is the benchmark doing this nosense, and how do I
> get paid to do it...
> 

For us the usecase is creating interfaces that get used by applications that 
generate all sorts of traffic. This allows us to simulate realistic end user 
traffic (e.g. coming from a full blown stack). That sounds reasonable to us :)

Also, I've seen other people reporting here to use more then 8000 interfaces.

> But I have to say no for another reason. You cause the kernel to choose
> a different name for the case where a device is deleted or renamed.
> The old code would find and fill the hole when a new device was added.
> 
> Since this is a semantic ABI change, the kind that drives users nuts.
> 

The intent was to keep the old behavior. When the device is deleted we stop 
fast allocation and we resume it only after we go through the old code once 
again. Did I miss something?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html