[vortex] MTU setting controls ?

[Matti Aarnio]

On Thu, Jan 04, 2001 at 01:00:24AM +1100, Andrew Morton wrote:
> Matti Aarnio wrote:
> > Hi,
> > 
> >   I need the card to support frames of larger than normal size,
> > and ways to do it seem to be simple at least in case one has 3c905B
> > (or latter) card.  One way to do it is to supply global 'mtu'
> > value of e.g. 1504, and let the existing code to handle the thing.
> 
> I'd suggest simply failing the MTU change if the device is open.
> That way, vortex_up() will take care of lots of initialisation.
> Does that work OK?  If you do:
> 
> 	ifconfig eth0 down
> 	ifconfig eth0 mtu 2000
> 	ifconfig eth0 up

	Or even (during system boot, starting in 'down' state)
		ifconfig eth0 <lots of params> mtu 2000 <more params> up
	works just fine.

> The 905C has a 256-slot multicast filter.  3com forgot to document
> the hashing algorithm, but there is an implementation in their
> 3c90x.c.
> 
> I'd be interested in Donald's opinion on the overall idea.
> 
> What's your timing on this?

	This century, preferred.  2.4.0 ?  Not necessarily.

	If it would cause more wide-spread activity of implementing
	missing multicast filters for hardware supporting them, all
	the better.

	Oh, and writing the RX IP(v4) TCP/UDP checksum checking would
	be neat, too.  (That is, copy it from 3Com driver ?)
	(Same story with intel.?)

>     I have a small amount of stuff which
> needs to go into 2.4.0 for the 3c905CX.  Then as soon as 2.4.1
> hits the streets Alexey has a patch which adds scatter-gather
> for the fragmented SKBs which are part of the zerocopy-sendfile
> changes.
> 
> I guess we could include this work in that changeset.

	Especially if there is a way to receive "larger" frames without
	upping the *visible* mtu of the device (say, allow receiving up
	to magic 36 bytes of slack built in every receive buffer).

	I recall we had some talk about the issue about 1/2 year ago, and
	your (or Donald's?) opinnion was that as it could (sometimes)
	excercise unproven "oversize frame" error handling path, such
	change should not be added...

	The VLAN tag stuff works by receiving up to 1504 byte payloads from
	physical interface, and if there is 0x8100 for protocol type tag,
	then it is sent to VLAN processing, header is analyzed, and frame
	is diverted to correct VLAN interface.

	However the 802.1Q management traffic goes out on untagged frames
	via the basic physical interface, thus I have:
		- eth0
		- eth0.vlan-nn
		- eth0.vlan-mm

	Each of those interfaces *should* have MTU 1500, but due to current
	technological limits,  eth0  must now have 1504 as its *advertised*
	MTU.  How can we change that ?  It needs to receive 1504 byte sized
	frames, but should not claim such capability to IP PMTU machinery.

	Host-Eth -> Switch-Eth/Switch-Trunk ->  eth0  -> eth0.vlan-nn
	 1500         1500        1504          1504     1500

/Matti Aarnio