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.
You mean you want to sacrifice "correctness" of implementation to speed?
I also was against moving headers around, until I encountered dhcp
Anyway, it is useless to argue about performance loss until someone actually
does benchmarks and provides us with real numbers. I don't see any
performance loss with ping -f.
> Ben> I like their idea, but it means they have to move the header
> Ben> around for each pkt. In mine, the packet is not modified, *BUT*,
> Ben> programs such as dhcpd which expect to be reading the raw
> Ben> ethernet pkt have to be modified.
> 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?
I think that the perfect solution will be to remove tags from frames
_only_ if some process actually reads ethernet headers from this vlan
device. Any ideas how this can be implemented?