[Top] [All Lists]

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

To: Gleb Natapov <gleb@xxxxxxxxxxxxxxxxxxxxx>
Subject: Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Sat, 03 Jun 2000 12:11:12 -0700
Cc: Rob Walker <rob@xxxxxxxxxxx>, buytenh@xxxxxxx, hadi@xxxxxxxxxx, netdev@xxxxxxxxxxx
Organization: Candela Technologies
References: <>
Sender: owner-netdev@xxxxxxxxxxx
Gleb Natapov wrote:
> On Fri, 2 Jun 2000, Rob Walker wrote:

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

In my opinion, processes should not break layering (ie read the MAC header)
unless they can deal with whatever they find there, correctly.  So, whether
or not it would be sacrificing correctness, is questionable.

Also, could there be some reason for giving the priority bits and VLAN ID
to the upper stack (not taking it out of the skb)?  Seems reasonable to
me, would be good for all kinds of traffic management...

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

There is definately a theoretical loss of performance in copying the header,
but it's only moving 14 bytes or so, so it really isn't that bad, and it's
probably only noise, statistically.

The more interesting question is which is actually more right!

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

I can't imagine how the VLAN layer could know what process the frames
were destined for...  I think it's definately something the user-space
processes should deal with.  (Note:  Patching DHCPd to fix it wasn't too hard.)

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

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