Alan Cox wrote:
> > + * NOTE: That is no longer true with the addition of VLAN tags. Not
> > + * sure which should go first, but I bet it won't make much
> > + * difference if we are running VLANs. The good news is that
> It makes a lot of difference tha the vlan goes 2nd. Most sane people wont
> have vlans active on a high load interface.
Um, what about people running their box as just a VLAN router/firewall?
That seems to be one of the principle uses so far. Actually, in that case
both VLAN and IP traffic would come through, so it would be a tie if VLAN
came first, but non-vlan traffic would suffer worse.
So, how can I make sure that it is second in the list?
> > strcpy(dev->name, buf);
> > return i;
> > }
> > }
> > - return -ENFILE; /* Over 100 of the things .. bail out! */
> > + return -ENFILE; /* Over 8192 of the things .. bail out! */
> So fix the algorithm. You want the list sorted at this point, or to generate
> a bitmap of free/used entries and scan the list then scan the map
Actually, VLAN code no longer uses this method to generate it's name,
it uses it's own mechanism (which, by the way, the hashed name lookup
makes much faster.) So, this part of the patch can be removed.
> Question: How do devices with hardware vlan support fit into your model ?
I don't know of any, and I'm not sure how they would be supported.
Ben Greear (greearb@xxxxxxxxxxxxxxx) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL)