Date: Wed, 16 Jun 2004 14:05:15 +0900 From: Pyun YongHyeon <yongari@kt-is.co.kr> To: Kevin Day <toasty@dragondata.com> Cc: freebsd-sparc64@freebsd.org Subject: Re: TCP/UDP cksum offload on hme(4) Message-ID: <20040616050515.GA8540@kt-is.co.kr> In-Reply-To: <264D82AE-BF4F-11D8-A89B-000A95A8A1F2@dragondata.com> References: <20040616034520.GB7887@kt-is.co.kr> <264D82AE-BF4F-11D8-A89B-000A95A8A1F2@dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 15, 2004 at 11:39:27PM -0500, Kevin Day wrote: > > 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. > The TX cksumming is performed during DMA by the hardware. So when the hardware computes the cksum I have no chance to reset to 0xffff. (i.e. The mbuf was already passed to TX FIFO.) I verified the deficiency with manually created UDP payload. Regards, Pyun YongHyeon -- Pyun YongHyeon <http://www.kr.freebsd.org/~yongari>;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040616050515.GA8540>