[vortex] 802.1q VLAN problem

Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de
Thu Apr 18 12:46:01 2002


On Wed, 17 Apr 2002, Ben Greear wrote:

> Just enabling the larger frame sizes does not mean that all of a sudden we'll
> be using 4k packets, so I think many of your concerns relating to switch support
> etc are not big problems.  Note that the standard VLAN setup does not increase
> the MTU of the ethernet interface, so the max sized packet will be just 4 bytes
> bigger than normal.

I can see that our views differ: I was thinking of adding over-sized frame 
support with the added benefit of supporting VLAN, while you are probably 
thinking about adding VLAN support with the added benefit of supporting 
over-sized frames. 8-)

> If there are performance tradeoffs, then just having a module variable to
> toggle VLAN or regular support would be much better than nothing.

I've taken a short look at the existing patches and it seems that the 
"always-on" mode of accepting VLAN or over-sized frames was already 
discussed. Probably a module option is the best solution, with the 
default "off". Is there any common name for such a module option ?

I've taken a look through the documentation and I found out that:

- Boomerang only has an "allowLargePackets" bit in MacControl register, so 
it's all-or-nothing. I don't have documentation for older chips.
- Cyclone has "allowLargePackets", but also has a "MaxPktSize" register 
which defines when the oversizedFrame error occurs.
- Tornado has "allowLargePackets", "MaxPktSize" and goes one step further 
with another MacControl bit (10) call "vlanOversizeEn" which if set, 
allows packets to be 4 bytes more than "MaxPktSize" before signaling the 
oversizedFrame error.

So, IMHO the easiest to add support for VLAN is Tornado where only the 
"vlanOversizeEn" bit should be set; for Cyclone, "MaxPktSize" should be 
set to MTU+4. As the method for Cyclone should work for both, we 
should probably use it in both cases in order not to introduce extra 
complexity in the code. OTOH, the driver doesn't take advantage of the MTU 
size, it only sets the "allowLargePackets" bit when MTU > 1500, all skb
allocations are done based on PKT_BUF_SZ, so to properly support different 
MTU sizes more changes to the driver are needed...

Any thoughts ?

-- 
Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De