From owner-freebsd-net@FreeBSD.ORG Sat Jul 14 02:30:56 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9773616A400 for ; Sat, 14 Jul 2007 02:30:56 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 6E09D13C428 for ; Sat, 14 Jul 2007 02:30:56 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id E1A399A85; Fri, 13 Jul 2007 22:30:55 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 13 Jul 2007 22:30:55 -0400 X-Sasl-enc: N04f8KdexVRz0GK1ybBT1oOKzWySAQTnffl4aQE/WBDK 1184380255 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 188FA62D1; Fri, 13 Jul 2007 22:30:54 -0400 (EDT) Message-ID: <4698355E.2030707@FreeBSD.org> Date: Sat, 14 Jul 2007 03:30:54 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: karels@karels.net References: <200707140106.l6E16HWi006607@redrock.karels.net> In-Reply-To: <200707140106.l6E16HWi006607@redrock.karels.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stephen.Clark@seclark.us, Sten Daniel Soersdal , Julian Elischer , Bill Moran , freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet 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: Sat, 14 Jul 2007 02:30:56 -0000 Mike Karels wrote: > I'd be happy to see the change undone as well. I (well, our test > group) found this change in a similar way, and it didn't agree with > our previous usage. > 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. Could be pilot error; its use in -CURRENT seems to apply strictly to the use of large-receive offload (LRO). regards, BMS