On Tue, Oct 03, 2000 at 09:09:22AM -0700, Jason R Thorpe wrote:
> 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.

I'm wondering about older chips. We should also document which ones can
do VLAN properly and which can't.

> 
> 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.

Ok.

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

But then is has to be static. So I guess this max len should be the
max len possible.

> 
> 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.

As pointed out by Daniel Hagerty, there are other encap protocols which may
require a different MTU. So I don't think the cap flag is enouth, we also need
the max possible length.

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

Ok, cool !

--
Manuel Bouyer <bouyer@antioche.eu.org>
--