kuznet@xxxxxxxxxxxxx wrote:
>
> Hello!
>
> > I rewrote the dev_alloc_name() function in the 2.2.14 Linux kernel's
> > net/core/dev.c module. It had an apparently artificial limitation on
> > number of network devices of the same type allowed (100),
>
> It is not artificial limitation but absolutely required fool-proof
> protection. Before creating more devices, you have to think about
> accesses to device list (which cannot be list after this, certainly).
Surely there are no critical paths that access the list linearly???
If that is the problem, then those should be fixed, based on the
device index or some other hash.
> To be honest, for now any attempt to make a module potentially
> creating large number of devices is pure bug, because their designers
> _know_ that accesses to device list are poorly programmed in core
> and _can_ organize code more friendly to existing infrastructure.
> VLAN is the best example of wrong approach, all these innumerous
> pseudo-devices do nothing useful but eating resources,
> one multipoint device is more than enough as rule.
What resources, other than memory, would the VLANs consume? I'm willing
to pay memory for constant-time lookups. If having many interfaces
hurts performance in some other way, then that is something I'd be
interested in fixing...
Although the VLAN code I've written will support an extremely large
number of VLAN devices, the common user will have between 1 and 10 I believe,
and most users will only have 1. I don't see any reason to make the code
less flexible just because _I_ don't think they need that many: They
may have reasons I've never considered... (low speed DSL/cable-modem
router/firewall?)
Still, if there's a better way, I'd like to look at it. Can you offer
an example of something that has many virtual interfaces, such as VLAN
does, but does not use many virtual net_devices? I think virtual-IP
interfaces use pseudo-devices, what about Frame-Relay PVCs? ATM PVCs?
Thanks,
Ben
>
> Alexey
--
Ben Greear (greearb@xxxxxxxxxxxxxxx) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL)
http://scry.wanfear.com http://scry.wanfear.com/~greear
|