| To: | Ben Greear <greearb@xxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ??? |
| From: | Mitchell Blank Jr <mitch@xxxxxxxxxx> |
| Date: | Mon, 5 Jun 2000 11:00:34 -0700 |
| Cc: | jamal <hadi@xxxxxxxxxx>, rob@xxxxxxxxxxx, buytenh@xxxxxxx, netdev@xxxxxxxxxxx, gleb@xxxxxxxxxxxxxxxxxxxxx |
| In-reply-to: | <393BC83B.67AD86BF@candelatech.com>; from greearb@candelatech.com on Mon, Jun 05, 2000 at 08:33:15AM -0700 |
| References: | <20000603091818.B48132@sfgoth.com> <Pine.GSO.4.20.0006040924390.16882-100000@shell.cyberus.ca> <20000604214856.B77216@sfgoth.com> <393B414B.ACF84B1B@candelatech.com> <20000605060321.E77216@sfgoth.com> <393BC83B.67AD86BF@candelatech.com> |
| Sender: | owner-netdev@xxxxxxxxxxx |
Ben Greear wrote: > Seems a hashtable would be nice for the ifindex.... The problemn with using a hashtable: how big should it be? After all you want it small enough that there isn't much memory waste if you have 3 devices, yet we can efficiently do a lookup on 10000 devices. That's why I'm thinking a B+ tree or something would be more appropriate. People on lkml occasionally talk about making a general tree implementation similar to <linux/list.h>.. does anyone know if there's code somewhere? > Also, if it takes out a linear search in a critical path (with seemingly > minimal overhead), then I don't even think it should be a configurable > option, just *IN* there! I personally agree, but since some people seem strongly against the idea it's a somewhat a matter of politics. -Mitch |
| Previous by Date: | Re: Possible bug in Space.c in 2.4.0-test1, Malware |
|---|---|
| Next by Date: | Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???, Benjamin C.R. LaHaise |
| Previous by Thread: | Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???, Ben Greear |
| Next by Thread: | Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???, Benjamin C.R. LaHaise |
| Indexes: | [Date] [Thread] [Top] [All Lists] |