Hi list,
I've recently been trying to create large-scale L2TPv3 configurations
of up to 50,000 Ethernet pseudowires.
One of the limitations I've hit has been to do with dev_alloc_name().
By default, l2tp_eth uses "l2tpeth%d" for device names, which is
expanded by dev_alloc_name() into l2tpeth1, l2tpeth2, etc. However,
the algorithm dev_alloc_name() uses to derive the next free number for
this scheme is bounded by the number of bits in a single page. For
kernels/platforms with a 4kB page, this limits these "autoderived"
names to 32k.
In my testing I've been able to work around this by specifying
interface names during the bringup of the l2tpeth interfaces, thereby
bypassing dev_alloc_name() altogether. Using this approach I am able
to comfortably create 50k interfaces, even on fairly modest hardware.
But it seems a shame to have to do this; it would be much nicer if
the kernel were able to autogenerate names for more devices.
Is this something that would be worth my working on a patch for, or
would the increased code complexity be too great an overhead to
consider for such outlandish use-cases?
Thanks,
Tom
--
Tom Parkin
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
On Thu, 2012-10-25 at 17:56 +0100, Tom Parkin wrote:
Hi list,
I've recently been trying to create large-scale L2TPv3 configurations
of up to 50,000 Ethernet pseudowires.
One of the limitations I've hit has been to do with dev_alloc_name().
By default, l2tp_eth uses "l2tpeth%d" for device names, which is
expanded by dev_alloc_name() into l2tpeth1, l2tpeth2, etc. However,
the algorithm dev_alloc_name() uses to derive the next free number for
this scheme is bounded by the number of bits in a single page. For
kernels/platforms with a 4kB page, this limits these "autoderived"
names to 32k.
In my testing I've been able to work around this by specifying
interface names during the bringup of the l2tpeth interfaces, thereby
bypassing dev_alloc_name() altogether. Using this approach I am able
to comfortably create 50k interfaces, even on fairly modest hardware.
But it seems a shame to have to do this; it would be much nicer if
the kernel were able to autogenerate names for more devices.
Is this something that would be worth my working on a patch for, or
would the increased code complexity be too great an overhead to
consider for such outlandish use-cases?
This issue was raised some ago, for the dummy device
modprobe dummy numdummies=33000
I guess each format (eg eth%d) could be attached/associated to an idr,
so that we can find the lowest available index very fast.
On Thu, 25 Oct 2012 19:50:43 +0200
Eric Dumazet [off-list ref] wrote:
On Thu, 2012-10-25 at 17:56 +0100, Tom Parkin wrote:
quoted
Hi list,
I've recently been trying to create large-scale L2TPv3 configurations
of up to 50,000 Ethernet pseudowires.
One of the limitations I've hit has been to do with dev_alloc_name().
By default, l2tp_eth uses "l2tpeth%d" for device names, which is
expanded by dev_alloc_name() into l2tpeth1, l2tpeth2, etc. However,
the algorithm dev_alloc_name() uses to derive the next free number for
this scheme is bounded by the number of bits in a single page. For
kernels/platforms with a 4kB page, this limits these "autoderived"
names to 32k.
In my testing I've been able to work around this by specifying
interface names during the bringup of the l2tpeth interfaces, thereby
bypassing dev_alloc_name() altogether. Using this approach I am able
to comfortably create 50k interfaces, even on fairly modest hardware.
But it seems a shame to have to do this; it would be much nicer if
the kernel were able to autogenerate names for more devices.
Is this something that would be worth my working on a patch for, or
would the increased code complexity be too great an overhead to
consider for such outlandish use-cases?
This issue was raised some ago, for the dummy device
modprobe dummy numdummies=33000
I guess each format (eg eth%d) could be attached/associated to an idr,
so that we can find the lowest available index very fast.
You could try vzalloc() instead of get_zeroed_page which would allow for
bigger bitmap.