Re: Call for re(4) checksum offload testers.

On Wed, Jan 24, 2007 at 07:14:03AM +0000, Bill Paul 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.
 > > Since there are lots of hardwares supported by re(4) I'd like to know
 > > whether the attached patch has no other regressions on re(4) hardwares.
 > > If there are no objections I'll commit it in a week.
 > > 
 > > Thanks.
 > > -- 
 > > Regards,
 > > Pyun YongHyeon
 > 
 > Unfortunately, your patch will break the rl(4) driver, which uses the
 > same header file and also uses RL_MIN_FRAMELEN (and which expects it to
 > be 60). Of course you can easily fix this by making rl(4) and re(4) use
 > different #defines. It may also be a regression for older 8169 cards.
 > There's already a workaround for a TX checksum offload problem wth
 > some of the PCI 8169 cards, which depends on RL_MIN_FRAMELEN being 60.
 > Changing RL_MIN_FRAMELEN may break the workaround for these chips.
 > 

Ah, I missed that. Thank you for pointing out.

 > I'm very confused as to why the chip botches the TX checksumming in
 > this case. Unfortunately, most of this confusion stems from the fact
 > that you didn't specify exactly which chip rev the user with this
 > problem has, or give a test case to trip the bug.
 > 

Sorry. Here is the information I've got from a user who owns
problematic hardware.

> laptop: Asus a6je
> card:   class=0x020000 card=0x11f51043 chip=0x816810ec rev=0x01 hdr=0x00
>         vendor=Realtek Semiconductor
>         device=RTL8168/8111 PCI-E Gigabit Ethernet NIC
>

On stock re(4) no TCP connections are available on this hardware.
Just type "http://www.gmail.com" on browser is sufficient to
reproduce on his hardware. If you want captured traffic I can sent
it for you even though it's captured on sending host with re(4).
I think you can easily spot which packets checksum were broken as
many TCP resends are repeated for a sequence number.

 > I'm assuming this yet another problem with small IP fragments being
 > mangled. That being the case, it should be possible to trip the bug
 > with "ping -s 1473 <somehost>." (1473 is 1 byte too large to fit into
 > a 1500 byte frame, which will cause a 1 byte fragment to be sent.)
 > I thought I tested this with my sample PCIe cards though, and didn't
 > see a problem. I'll have to try it again tomorrow.
 > 

It seems that the hardware in question does not like extra padded
bytes for TCP packets. AFAIK the hardware worked without any paddings
for non-TCP packets. I couldn't test UDP case due to lack of hardwares
but I guess this paticular chip has a working checksum offload
implementation. I could have checked a chip revision for the padding 
work-around but I can't sure which revisions would break the assumtion
so I followed NetBSD approach. I've searched all NetBSD archives for
the re(4) checksum offload issues but I've failed to find so I thought
their fix really works for most hardwares.

AFAIK the originator said that "ping -s 1473" without padding work-around
also worked on his system. So I guess it breaks checksum only if it sees
extra padded bytes in TCP packet.

 > In any case, you can't check this patch in as-is. It may fix things
 > for this one particular NIC, but it will break things for others.
 > 

Ok, I'll wait for your results and opinions.
Thank you very much for looking this issue!

 > -Bill
 > 
 > --
 > =============================================================================
 > -Bill Paul            (510) 749-2329 | Senior Engineer, Master of Unix-Fu
 >                  wpaul_at_windriver.com | Wind River Systems
 > =============================================================================
 >               <adamw> you're just BEGGING to face the moose
 > =============================================================================

-- 
Regards,
Pyun YongHyeon