netdev
[Top] [All Lists]

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

To: gleb@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???
From: Rob Walker <rob@xxxxxxxxxxx>
Date: Sat, 3 Jun 2000 09:49:29 -0700 (PDT)
Cc: rob@xxxxxxxxxxx, greearb@xxxxxxxxxxxxxxx, buytenh@xxxxxxx, hadi@xxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <Pine.OSF.3.96-heb-2.07.1000603124733.9769A-100000@tochna.technion.ac.il>
References: <14648.24946.413472.365255@tungsten.su.valinux.com> <Pine.OSF.3.96-heb-2.07.1000603124733.9769A-100000@tochna.technion.ac.il>
Reply-to: rob@xxxxxxxxxxx
Sender: owner-netdev@xxxxxxxxxxx
>>>>> On Sat, 3 Jun 2000 13:03:40 +0300 (IDT), Gleb Natapov
>>>>> <gleb@xxxxxxxxxxxxxxxxxxxxx> said:

Gleb> On Fri, 2 Jun 2000, Rob Walker wrote:

Ben> On this account, my vlan implementation, and Lenert and Gleb's
Ben> are almost identical.  Other than some internal issues, I believe
Ben> the only user-visible difference between my imp and theirs is
Ben> that they re-write the packet header on the way upthe stack so
Ben> that it looks **exactly** like an ethernet pkt, where as I just
Ben> leave the header alone and pull 4 extra bytes off of the SKB
Ben> before giving it to the higher levels.

>> Remember how hard *BSD keeps ragging that their stack isfaster due
>> to "zero copy"?  I can't evaluate whether that statement is true,
>> or if the speed advantage has worn off with time, but I do think
>> that the faster the implementation, the better.

Gleb> You mean you want to sacrifice "correctness" of implementation
Gleb> to speed?  I also was against moving headers around, until I
Gleb> encountered dhcp problem.

I am not sure about that one.  Muct think more about it.


Gleb> Anyway, it is useless to argue about performance loss until
Gleb> someone actually does benchmarks and provides us with real
Gleb> numbers. I don't see any performance loss with ping -f.

Yes, benchmarking numbers should be taken on by someone somewhere.  I
would love to see linux up at the PPP bake-offs in San Ramon, and at
any other gathering of the heavyweights to do benchmarks.  I think
that this will not happen until a company has a vested interest in a
commercial solution of this type.  something-xylink or
xylink-something is the only company I know of doing linux
routers/switches in a chassis-based solution.  I can't even find their 
site right now, so those names are probably a ways off.

>> Maybe a run-time switch could be added to dhcpd, or you could
>> extend it to automatically read both types of frames as detected.
>> Is this even possible?

Gleb> I think that the perfect solution will be to remove tags from
Gleb> frames _only_ if some process actually reads ethernet headers
Gleb> from this vlan device. Any ideas how this can be implemented?

As far as 

Gleb> I also was against moving headers around, until I encountered
Gleb> dhcp problem.

maybe this is a time where dhcpd needs to be updated to follow the new 
interface standard?  Interfaces change, and the applications which use 
those interfaces need to be updated.  

another thought along the same lines is that if I have set up dhcpd to 
answer only off of certain subnets, but those subnets are on different 
vlans, doesnt' dhcpd need to know which vlan it came in on?
(therefore it needs to be able to read the vlan tag, and get the
entire packet with the tag intact)

rob

-- 
I want the TCP/IP equivalent of a Rat Thing.  -- James W. Abendschan

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