TCP/UDP cksum offload on hme(4)

Pyun YongHyeon yongari at kt-is.co.kr
Wed Jun 16 05:07:16 GMT 2004


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>


More information about the freebsd-sparc64 mailing list