> > I do use a vlan lookup table, did you think I do a linear search through
> > the vlans for incomming pkts or something??? As far as I recall, every
> > lookup involved in any critical path is constant time. That is one of
> > the reasons I believe my implementation will scale better than the
> > other project... (could be wrong...)
> I just scanned through the other code and this is _exactly_ what i had in
> mind. ccing the authors incase they are not in the list.
> Their scanning algorithm certainly needs improvement
We use hash table currently. Why do you think it is inefficient? How
many vlans are you expecting to have on each device? You can tune
performance by changing hash table size if you wish.
Anyway, it is very easy to change ADT from hash table to something else.
What do you suggest?
> > A VLAN should look just like an ethernet port. I **WANT** it to look
> > exactly like a device, so why not actually make it one?? I want to
> > use tcpdump on it,
> Modify tcpdump to do Vlan recognition (if it doesnt already).
Also don't forget to modify dhspd and, I suppose, many other programs,
and to tell to everyone out there to write code that can handle extra
header in ethernet frame from now on ;)
> > I want to route, firewall, bridge and do everything
> > else that a device would do.
> VLANs are primarily for switching. Fair enough that you want to route
Vlans are for switching but vlan tags are not IMO.
> them. But you can certainly still do this with policy routing for example.
> The only place i see routing taking effect is in the boundary between
> VLANs and non-VLAN domains.
> Out of ignorance: Is there anyone (vendor) who does routing of VLANs?
I think that everyone who uses current vlan implementations does just
that. Am I right?
> firewalling: I believe the bridging folks are trying to move
> netfilter/ipchains down there; i dont know what the progress status is.
> > How can that be done if the VLAN is not
> > a device, and if it could be done, why would it be any more efficient?
> Again from the above, you really dont need a device.
> Really, take a look at James Leu's MPLS which is a similar (introduces the
> extra shim headers etc) but a more complex issue. He doesnt introduce any
> new devices.
I want to look at this. Can you provide some URLs?
> Use a table or whatever structure (radix tree etc); allow search by
> VLANid, priority etc;
> With these you are free to put whatever search schemes, naming conventions
> etc that you want instead of subjecting the rest of the kernel to
> something that you need for your feature.
> In any case when there are two solutions, they need to get unified before
> making it into the kernel proper.
Since I didn't participate in this discussion until now I don't know
what are you talking about :).