From owner-freebsd-net@FreeBSD.ORG Sun Aug 21 04:09:24 2011 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 553F3106564A for ; Sun, 21 Aug 2011 04:09:24 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (mail.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id 376AB8FC0C for ; Sun, 21 Aug 2011 04:09:23 +0000 (UTC) Received: from [192.168.4.185] ([88.96.1.126]) by exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 20 Aug 2011 21:09:23 -0700 From: Ben Hutchings To: freebsd-net@freebsd.org In-Reply-To: <17D3FAD0-1372-45BA-B4A1-02840B925F1F@gmail.com> References: <4E4E3522.6030207@gmail.com> <1313806260.2814.57.camel@deadeye> <17D3FAD0-1372-45BA-B4A1-02840B925F1F@gmail.com> Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Communications Date: Sun, 21 Aug 2011 05:09:17 +0100 Message-ID: <1313899757.3142.13.camel@deadeye> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Aug 2011 04:09:23.0359 (UTC) FILETIME=[1BE622F0:01CC5FB8] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18334.005 X-TM-AS-Result: No--21.703400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: Test tools for new network driver 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: Sun, 21 Aug 2011 04:09:24 -0000 On Sat, 2011-08-20 at 11:18 +0100, Ben Gray wrote: > Thanks everyone, > > Cheers for the tips on the mac address, I must admit I wasn't aware > of the locally assigned bit in the address. > > As for H/W checksum offloading, the main problem is the datasheet > for the chip is under NDA which I'm unwilling to sign, so I'm working > off the Linux driver. It seems under Linux if the TCP/UDP checksum > fails it reverts to a software calculation and as far as I can tell > FreeBSD doesn't do this. Hence it seems under Linux the driver reports > incorrect csums but the kernel covers up for it. [...] That's right. Linux doesn't entirely trust hardware checksum validation, so drivers can't report that the checksum was definitely bad. You should be able to get this behaviour on FreeBSD by not setting any checksum flags if the hardware says the checksum is bad. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked.