From owner-freebsd-net@FreeBSD.ORG Fri Apr 27 23:11:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2238106566B; Fri, 27 Apr 2012 23:11:54 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.freebsd.org (Postfix) with ESMTP id BE8A48FC08; Fri, 27 Apr 2012 23:11:54 +0000 (UTC) Received: from [10.9.208.27] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 27 Apr 2012 16:08:50 -0700 X-Server-Uuid: 72204117-5C29-4314-8910-60DB108979CB Received: from IRVEXCHCAS07.corp.ad.broadcom.com (10.9.208.55) by irvexchmb05.corp.ad.broadcom.com (10.9.208.27) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 27 Apr 2012 16:08:39 -0700 Received: from IRVEXCHMB11.corp.ad.broadcom.com ( [fe80::9cdd:3a57:8694:f610]) by IRVEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Fri, 27 Apr 2012 16:08:39 -0700 From: "David Christensen" To: "pyunyh@gmail.com" , "Andrey Zonov" Thread-Topic: bce: jumbo not working since r218423 Thread-Index: AQHNI58ETiBicQtXXEaswP/sqsS0Y5avwioA//+KO9A= Date: Fri, 27 Apr 2012 23:08:38 +0000 Message-ID: <3A5015FE9E557D448AF7238AF0ACE20A129751@IRVEXCHMB11.corp.ad.broadcom.com> References: <20120427230400.GB17009@michelle.cdnetworks.com> In-Reply-To: <20120427230400.GB17009@michelle.cdnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.145.68] MIME-Version: 1.0 X-WSS-ID: 6385F8883JG1867102-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , "davidch@freebsd.org" Subject: RE: bce: jumbo not working since r218423 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 23:11:55 -0000 >> 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