Subject: Re: 802.1Q & ETHER_MAX_LEN
To: Jason R Thorpe <email@example.com>
From: Manuel Bouyer <firstname.lastname@example.org>
Date: 10/03/2000 21:01:25
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.
> ....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 <email@example.com>