From owner-freebsd-sparc64@FreeBSD.ORG  Wed Jun 16 04:37:35 2004
Return-Path: <owner-freebsd-sparc64@FreeBSD.ORG>
Delivered-To: freebsd-sparc64@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 4A4E016A4CE
	for <freebsd-sparc64@freebsd.org>;
	Wed, 16 Jun 2004 04:37:35 +0000 (GMT)
Received: from mail.dragondata.com (server3-a.your.org [64.202.112.67])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 1FFEB43D4C
	for <freebsd-sparc64@freebsd.org>;
	Wed, 16 Jun 2004 04:37:35 +0000 (GMT)
	(envelope-from toasty@dragondata.com)
Received: from localhost (localhost.your.org [127.0.0.1])
	by mail.dragondata.com (Postfix) with ESMTP id 939D33D18CC;
	Tue, 15 Jun 2004 23:37:34 -0500 (CDT)
Received: from mail.dragondata.com ([127.0.0.1])
 by localhost (server3.dragondata.com [127.0.0.1]) (amavisd-new, port 10024)
 with LMTP id 07069-03-14; Tue, 15 Jun 2004 23:37:34 -0500 (CDT)
Received: by mail.dragondata.com (Postfix, from userid 1000)
	id 067CD3D189B; Tue, 15 Jun 2004 23:37:34 -0500 (CDT)
Received: from [199.165.179.45] (ppp045.dhcp.your.org [199.165.179.45])
	(using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by mail.dragondata.com (Postfix) with ESMTP id B05853D1943;
	Tue, 15 Jun 2004 23:37:32 -0500 (CDT)
In-Reply-To: <20040616034520.GB7887@kt-is.co.kr>
References: <20040616034520.GB7887@kt-is.co.kr>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <264D82AE-BF4F-11D8-A89B-000A95A8A1F2@dragondata.com>
Content-Transfer-Encoding: 7bit
From: Kevin Day <toasty@dragondata.com>
Date: Tue, 15 Jun 2004 23:39:27 -0500
To: yongari@kt-is.co.kr
X-Mailer: Apple Mail (2.618)
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 
	server3.dragondata.com
X-Spam-Level: 
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63 
	languages=en, sco bayes=0.5
X-Virus-Scanned: by amavisd-new at dragondata.com
cc: freebsd-sparc64@freebsd.org
Subject: Re: TCP/UDP cksum offload on hme(4)
X-BeenThere: freebsd-sparc64@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Porting FreeBSD to the Sparc <freebsd-sparc64.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64>,
	<mailto:freebsd-sparc64-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-sparc64>
List-Post: <mailto:freebsd-sparc64@freebsd.org>
List-Help: <mailto:freebsd-sparc64-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64>,
	<mailto:freebsd-sparc64-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Jun 2004 04:37:35 -0000


On Jun 15, 2004, at 10:45 PM, Pyun YongHyeon wrote:
>
>  1. UDP TX cksum offload has an issue. The hardware doesn't flip the
>     cksum bits when the computed cksum is 0x0000. I have no idea this
>     is the reason why STP2002QFP says it supports only TCP RX/TX cksum.
>     (pp. 29, pp. 40, pp. 42)
>
>

I'm not sure if you're aware of this or not, but:

> If the computed  checksum  is zero,  it is transmitted  as all ones 
> (the
> equivalent  in one's complement  arithmetic).   An all zero  
> transmitted
> checksum  value means that the transmitter  generated  no checksum  
> (for
> debugging or for higher level protocols that don't care)


So, if a UDP packet has an all zero checksum, it's supposed to mean 
there was no checksum performed. If you legitimately came up with 
0x0000 for a checksum, you're supposed to set the header field to 
0xffff.