Date: Fri, 27 Apr 2012 23:08:38 +0000 From: "David Christensen" <davidch@broadcom.com> To: "pyunyh@gmail.com" <pyunyh@gmail.com>, "Andrey Zonov" <andrey@zonov.org> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, "davidch@freebsd.org" <davidch@freebsd.org> Subject: RE: bce: jumbo not working since r218423 Message-ID: <3A5015FE9E557D448AF7238AF0ACE20A129751@IRVEXCHMB11.corp.ad.broadcom.com> In-Reply-To: <20120427230400.GB17009@michelle.cdnetworks.com> References: <CANU_PUGwoLSrPcGE8wT=ga3-=F_n9qN4pPXMJC%2BH72wpS9Mfcw@mail.gmail.com> <20120427230400.GB17009@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> I also don't understand why sysctl hw.bce.loose_rx_mtu doesn't respect >> with tunnable hw.bce.strict_rx_mtu. Is there any reason to give them >> different names? >It may be an oversight. Personally I don't see any reason except >debugging purpose to limit RX frame size to interface MTU. It makes >sense when controller send frames but it should be able to receive >any sized RX frames(if controller allows it). Dropping RX frames >that are bigger than interface MTU would break path MTU discovery >of remote host that uses bigger MTU. The intent was to pass compliance tests such as those performed at UNH by limiting the MTU to the size allowed by the IEEE 802.3 specification. (No one likes explaining such failures to customers.) As you indicate, rea= l=20 world applications benefit from loose compliance on RX so a single tunable is all that's intended to enable/disable the behavior. Dave
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A5015FE9E557D448AF7238AF0ACE20A129751>