Date: Sat, 14 Jul 2007 13:05:48 -0700 From: Sam Leffler <sam@errno.com> To: karels@karels.net Cc: Bill Moran <wmoran@collaborativefusion.com>, Stephen.Clark@seclark.us, Julian Elischer <julian@elischer.org>, freebsd-net@freebsd.org, "Bruce M. Simpson" <bms@freebsd.org>, Sten Daniel Soersdal <netslists@gmail.com> Subject: Re: 6.2 mtu now limits size of incomming packet Message-ID: <46992C9C.8040308@errno.com> In-Reply-To: <200707140327.l6E3RqWA007006@redrock.karels.net> References: <200707140327.l6E3RqWA007006@redrock.karels.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Karels wrote: >> In -CURRENT my changes to the ethernet input path maintain the use of >> ETHER_MAX_FRAME() however the check is folded under #ifdef DIAGNOSTIC. I >> don't recall adding this conditional or touching it so it seems to be >> something which was already thereo radded by someone else. > > It has been there at least since 6.0. The issue is that ETHER_MAX_FRAME > is computed using ifp->if_mtu, as opposed to something like ETHER_MAX_LEN. > This is under #ifdef DIAGNOSTIC in -current, not in -stable. > >> Could be pilot error; its use in -CURRENT seems to apply strictly to the >> use of large-receive offload (LRO). > > LRO relaxes the requirement, otherwise LRO packets would never pass the > check. I can't recall if I brought the check in when I moved a lot of common logic out of 802.3 drivers' rx intr handler or if it pre-dated that. I believe the code is shared with netbsd (which I cross-checked when I did that cleanup work). I think removing it is fine. As has been said mtu was never intended to be applied to the rx path. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46992C9C.8040308>