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 YongHyeonReceived on Mon Jan 22 2007 - 08:44:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:05 UTC