Subject: Re: 802.1Q & ETHER_MAX_LEN
To: Manuel Bouyer <bouyer@antioche.lip6.fr>
From: Jason R Thorpe <thorpej@zembu.com>
List: tech-net
Date: 10/03/2000 09:09:22
On Sun, Oct 01, 2000 at 09:35:24PM +0200, Manuel Bouyer wrote:

I guess I should chime in, here :-)

 > There are several issue here:
 > - hardware: does the ethernet adapter supports frames of 1522 bytes ?
 >   I looked quickly at the tulip and smc83c170 sources and found no way to
 >   change this, it looks like the 1518 bytes values is hardcoded in hardware.
 >   Does anyone know if there are (10/100) ethernet chips that can send/receive
 >   frames bigger than the standart len ?

You simply need to enable reception of "bad" frames.  You can do this on
the Tulip by ignoring the Receive Watchdog Timeout error (RWT indicates
that the packet reception took more clocks than expected).  You can do this
on the Intel i82557 and several others.

What we can do is similar to what I did for promiscuous mode checking; always
enable reception of bad frames (up to the buffer size provided by the driver,
which is MCLBYTES for most of the PCI drivers), and then have the upper layer
drop them if > "the right size".  We could compute "the right size" with a
macro like so:

#define	ETHER_MAX_FRAME(etype, mflags)					\
	(ETHERMTU + ETHER_HDR_LEN + 					\
	 (((mflags) & M_HASFCS) ? ETHER_CRC_LEN : 0) +			\
	 (((etype) == ETHERTYPE_VLAN) ? ETHER_VLAN_ENCAP_LEN : 0))

...or something.

...as for the hardware side, again, drivers could silently enforce the
maximum packet len.

We may also want some sort of "capabilities" flags word inside the ethercom
structure, as well as some sort of "enable feature" flags word, which we
could kick into action with an SIOCSIFFLAGS ioctl.

Anyway, I'm cooking up a patch for this... stay tuned.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>