On Sat, 3 Jun 2000, Ben Greear wrote:
> 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!
We are talking about two different things. 'ports' are _physical_. So you
only had two ports; and unless you really understand CISCOs internal
structuring, no point in making references to their 200 'devices'
(that could be just the user interface showing stuff that
people like to see).
> > 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
> (ATM, FR, VLAN) can do whatever makes the most sense for it.
I dont follow.
> > 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
You register_netdevice() each VLAN device (because you have a device for
> 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
> which is fairly non-standard.
I am not gonna bitch about how many devices you have but in most cases
1024 per device is already overkill (including cross port VLANs).
So in the worst case for 4 ethernet ports you have grown dev_base to over
15000 structures (in the worst case). Now go look at the associated code
and tell me you dont see the repurcasions.
If you know of a smart way to optimize that please post it. You might get
me to support you.
Most of the manipulating code doesnt run in the critical data path, but
you are adding unnecessary noise, and besides my point is that _you dont_
need to have a device per VLAN; i might convert if you optimize it for
> 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.
Ok so they use BPF. Either out of coolness or madness. Would packet socket
have sufficed here for Linux ?