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