Call for re(4) checksum offload testers.
Pyun YongHyeon
pyunyh at gmail.com
Mon Jan 22 09:44:53 UTC 2007
On Mon, Jan 22, 2007 at 05:24:54PM +0800, Sepherosa Ziehau wrote:
> On 1/22/07, Pyun YongHyeon <pyunyh at gmail.com> wrote:
> >Hi,
> >
> >It seems that some revisions of re(4) hardwares(PCIe variants?) still
> >have Tx checksum offload issues. One user reported the issue said
> >the attached patch fixed the issue on his box.
>
> -#define RL_MIN_FRAMELEN 60
> +/*
> + * re(4) hardware IPv4 Tx checksum offload could be mangled with 28 bytes
> + * or less IP packets.
> + */
> +#define RL_TXCSUM_MINLEN 28
> +#define RL_MIN_FRAMELEN (ETHER_HDR_LEN + RL_TXCSUM_MINLEN)
>
> Does you patch mean a buggy PCIe re(4) will trash small packets padded
> to 60bytes but will not trash small packets padded to 42bytes? If
Yes.
> "yes" is the answer, then why normal packets whose size is 60bytes
> will not be trashed by a buggy PCIe re(4)?
>
I don't know(Only RealTek knows the details). But it seems that
hardware's SM for checksum computation was confused by the padding
bytes and subsequent small (retransmitted) packets which has less
than a threshold frame length bytes were mangled.
Maybe it didn't see extra padding bytes so its SM worked as expected.
> IMHO, "fixing buggy PCIe re(4) txcsum" is not NetBSD's original
> intention to narrow down the size of packets that will trigger the
> re(4) txcsum bug.
>
Agreed. But it also fixed buggy checksum bugs in PCIe variants which
does not like to expect extra padded bytes.
> Best Regards,
> sephe
>
> --
> Live Free or Die
--
Regards,
Pyun YongHyeon
More information about the freebsd-current
mailing list