[vortex] MTU setting controls ?

[Donald Becker]

On Wed, 3 Jan 2001, Matti Aarnio wrote:

>   I need the card to support frames of larger than normal size,
...
> There really should be separate ways to set the actual maximum received
> packet size, and the interface-MTU -- I really would not like to tell to
> IP/TCP that the interface MTU is larger than 1500, so that I could receive
> VLAN tagged frames at the shared physical interface.

VLAN support is a special case with later 3c905 cards.
The IP checksum hardware must understand VLAN headers, so there is explicit
support for MTUs of 1500 and 1500+4.
In addition most EL-XL cards support almost-FDDI size frames of about 4500
bytes.  The FDDI-size enable is the current oversized-MTU bit being set 
    bit 0x40 in Wn3_MAC_Ctrl

> Another issue with Vortex cards is that they don't seem to have multicast
> reception filter machinery, while *some* (newer) cards have working multicast
> filters, those have no need to blindly receive all multicasts!

Bonus: The early multicast filter implementation was conceptually broken.
You didn't know which filter bits that you were writing.

> A generic network layer statistics thing is that there apparently is no
> counter for broadcasts, and multicasts and broadcasts do get folded into

I'll respond to this with a longer letter.  The essential point are
  I had a proposal about four years ago that added a bunch of new fields
  That proposal is still mostly valid.

  /proc/net/dev cannot be changed.  I was unhappy when it was changed the
  last time: we are still getting "bug" reports  broke, and it broke my
  carefully summarized fields that fit in 80 columns, but still didn't emit
  all of our existing counter values

  Statistics should be re-ordered to be cache line friendly.

  A driver should be able to get a statistics table in net_device, or at
  least register its private table, so that low-overhead access to
  approximate statistics is available.

> - Changes done to 3c59x.c driver (my test machine has these)
>   are "a bit" shaky -- the  change_mtu()  function clearly needs
>   to poke at the card at selected moments, but it is *VERY*
...
>    Ball to driver specialists.)

You should only be able to increase the Rx MTU past 1500 when an Ethernet
device is down, assuming that you can change it to >1500 at all.

Changing the Rx MTU requires shutting down the receiver and re-allocating
all of the Rx buffers.  This is just like changing the station
address: if you have to shut down the card's receiver anyway, why add
complexity into the driver?  Just have the user-level code do the down+up.

> - There is   vortex_set_mtu()  -- actual register poking is questionable
>   code in live system

Switching to window 3 should be mostly OK, but you will need to hold the
register window lock.

> +	vp->pkt_buf_sz = mtu + 36; /* FIXME: What is this MAGIC 36 ??? */

IMPORTANT DETAIL!!
The Ethernet drivers try to always allocate 1536 (3*512) byte blocks.
Most cards use slightly fewer bytes, but when you have two different card
you don't want to mix up the allocation pool with two slightly different
sizes (e.g. both 1520 and 1532 byte buffers).

Typical Rx buffer sizes
  1514 		Basic maximum Ethernet packet size w/headers
    +4 		Packet with 4 byte CRC
    +2		Align the IP header		
   +16		Prepend a descriptor

> +	vp->pkt_buf_sz = mtu + 36; /* FIXME: What is this MAGIC 36 ??? */

This is hack to do
	vp->pkt_buf_sz = mtu < 1500 ? 1536 : round_up(mtu + 2);


Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993