[vortex] 802.1q VLAN problem
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
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 ?
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868