[Top] [All Lists]

Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Wed, 31 May 2000 21:37:44 -0700
Cc: netdev@xxxxxxxxxxx
Organization: Candela Technologies
References: <Pine.GSO.4.20.0005312016180.10393-100000@xxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
jamal wrote:
> Ben,
> Your architecture of maintaining a device per VLAN does not scale;
> (as you might have heard from your numerous attempts to change device
> lookups).

I have no intention of changing device lookups.  I did write my own method
of naming them, but that's quite trivial.

> What is the specific reason that you insist on mapping a VLAN to a device?
> Have you thought of using a VLAN lookup table instead?

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...)

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, I want to route, firewall, bridge and do everything
else that a device would do.  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?

Doesn't Frame Relay and ATM PVCs have the exact same problem?

I keep hearing that it doesn't scale, but I think that is a problem that
should be fixed elsewhere, if its true.
I can see no logical reason why adding devices should
have a linear slowdown on critical paths.

If one is too squeamish to deal with an ifconfig -a that takes
forever, I'm sure one could write ifconfig to be faster, but it
doesn't really matter, because the people who want lots of interfaces,
want lots of interfaces.  Ever configured 100 FrameRelay pvcs on a
Cisco?  It sucks to print out the config, but it works just fine.

> cheers,
> jamal
> I am only asking because i think that sooner than later we need to have
> 802.1p/q in the kernel and your current scheme is problematic.

I haven't looked at the higher protocols, so if you can point out a real
deficiency that multiple interfaces cause, and can suggest any other way
of doing multiple interfaces without doing multiple interfaces, please
let me know!

> BTW, it seems there is another 802.1p/q project at sourceforge;

Yes, there is a link from my page to theirs.  I was under the impression
that they use multiple interfaces too, just that they put them in a linked
list (slaved off of an ethernet device), instead of in an indexed table like
I do.  This would imply to me that their solution really wouldn't be too great
if they put 100 VLANs on a single NIC.  They may have changed their 


Ben Greear (greearb@xxxxxxxxxxxxxxx)
Author of ScryMUD: 4444        (Released under GPL)     

<Prev in Thread] Current Thread [Next in Thread>