netdev
[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: Sat, 03 Jun 2000 13:03:11 -0700
Cc: rob@xxxxxxxxxxx, buytenh@xxxxxxx, netdev@xxxxxxxxxxx, gleb@xxxxxxxxxxxxxxxxxxxxx
Organization: Candela Technologies
References: <Pine.GSO.4.20.0006030945230.15626-100000@xxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
jamal wrote:

> Infact i have never seen a single switch blade with more than 48 ports
> but even that is beside the point. The point really is the desiugn
> abstraction.

I had a cisco with two FrameRelay 'ports' on it.  I added 200 PVC
'devices' to the cisco setup.  Last time I'll mention it, so remember it!

> I will argue that you _can not_ write a generic search algorithm for all
> these protocols. Unfortunately if you enforce one  then the device search
> algorithm will have to be the same across the  board.

I see no need to even have a generic search algorithm, each protocol 
implementation
(ATM, FR, VLAN) can do whatever makes the most sense for it.

> It goes without any arguement that we have a very good worst case estimate
> today, given the practical limits. You try adding all those thousands of
> VLANs as devices and i can _guarantee you_ that you are not optimizing for
> the common case.

Ok, the question is where is the lookup 'hit' you are talking about.
Where is this searching that is slowing everything down?  Don't just
say there is a hit, show me the specific code or logic where this hit takes 
place.

For incomming pkts, the packet is detected in eth.c, as it comes off
of the hardware.  I can immediately hash to find the VLAN device.
Constant time, worst case, O(n), where n is the number of physical ethernet
ports, and this is only when configured to allow 4096 VLANs PER Ethernet device,
which is fairly non-standard.

After that, the packet goes on up the stack, as if it were from any other
device.  

So, I see no performance hit going up the stack, regardless of how many
devices you have...


Now, going down the stack, I know less about.  However, it's something like:
send on a socket, which then looks at the routing to determine the interface 
(net_device),
then send it out that device.  Where is the lookup/search problem here?  Surely 
the
IP stack is not so dumb that it must do a linear search on the net_device 
linked list??
That would blow your performance to hell even if you only have 5-10 interfaces.

So, please either provide some concrete examples where having more devices
hurt performance, or quit arguing about it.

> I like Lennert and Gleb's because they dont use devices for the
> abstraction rather they attach themselves to the device. You dont.

I'm not sure you are correct here, Gleb, Lennert?  Either way, my VLANs
are **logically** attached to devices, even if they don't have pointers
linked off of the ethernet device.

> You could use the aliasing interface if you wanted to add extra IP
> addresses (one per VLAN).

Maybe I want to add 20 IP aliases to a VLAN?

> I dont understand the DHCP problem. What has an app got to do with
> what happens at layer 2?

I do, DHCP uses packet filters and uses hard-coded offsets into the
raw packet.  The 4 extra bytes throw it off by 4, and so it never things
it gets a packet on the right port.  See the patch on my web site if you
want to learn more.

Ben

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

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