Date: Mon, 25 Jun 2001 17:23:18 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Jonathan Lemon <jlemon@flugsvamp.com>, Yar Tikhiy <yar@FreeBSD.ORG>, audit@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Long ether frames & MTU Message-ID: <20010625172318.C33375@prism.flugsvamp.com> In-Reply-To: <20010626075624.D95583@gsmx07.alcatel.com.au> References: <20010625230255.A11496@comp.chem.msu.su> <20010625142542.Z33375@prism.flugsvamp.com> <20010626075624.D95583@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 26, 2001 at 07:56:24AM +1000, Peter Jeremy wrote:
> On 2001-Jun-25 14:25:42 -0500, Jonathan Lemon <jlemon@flugsvamp.com> wrote:
> >On Mon, Jun 25, 2001 at 11:02:55PM +0400, Yar Tikhiy wrote:
> >> Hi there,
> >>
> >> While more and more Ethernet NIC drivers start supporting long
> >> frames (>1518 bytes), the user/admin still cannot raise MTU on an
> >> Ethernet interface above the 1500 byte limit due to outdated code
> >> in net/if_ethersubr.c
> [patch removed]
>
> >I'm not at all sure how this change will help anything, unless each
> >driver alters if_hdrlen.
>
> One benefit is for 802.1Q VLAN support - the existence of lots of
> hard-wired values that restrict frames to 1518 bytes makes configuring
> VLAN's a pain. It would be nice if attaching a vlan(4) to a driver that
> handled 1522 byte frames resulted in a 1500 byte MTU on the vlan.
Maybe I'm being dense here, but even with 1522 byte frames, the MTU
of the device should still be 1500. MTU in this context applies to IP,
so it wouldn't include either the vlan header or the ethernet header.
E.g.: there is this check in vlan_config():
if (p->if_data.ifi_hdrlen == sizeof(struct ether_vlan_header))
ifv->ifv_if.if_mtu = p->if_mtu;
else
ifv->ifv_if.if_mtu = p->if_data.ifi_mtu - EVL_ENCAPLEN;
So if the underlying device is willing to support long frames (which
is indicated by hacking in a longer headerlen), the vlan MTU is 1500,
and the device MTU is 1500. If the underlying device does not support
long frames, then the vlan MTU is reduced appropriately.
> > Drivers which actually are able
> >to handle a larger mtu (e.g: 9000 byte Jumbograms) already have to do
> >their own checks, and thus don't call this function.
>
> IMHO, it would be nicer if more of the checking was centralised, rather
> than each driver repeating the same checks.
It might be cleaner if the call to ether_ioctl() passed both the
proposed MTU and the maximum MTU that the driver is willing to
support. However, that would require quite a bit of code restructuring
and modifications to existing drivers. I'm not sure it would provide
any benefits, as the code in question is a simply a single 'if' statement.
--
Jonathan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-audit" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010625172318.C33375>