net: aquantia: tcp checksum 0xffff being handled incorrectly
authorNikita Danilov <ndanilov@aquantia.com>
Sat, 25 May 2019 09:58:05 +0000 (09:58 +0000)
committerDavid S. Miller <davem@davemloft.net>
Mon, 27 May 2019 17:24:14 +0000 (10:24 -0700)
Thats a known quirk in windows tcp stack it can produce 0xffff checksum.
Thats incorrect but it is.

Atlantic HW with LRO enabled handles that incorrectly and changes csum to
0xfffe - but indicates that csum is invalid. This causes driver to pass
packet to linux networking stack with CSUM_NONE, stack eventually drops
the packet.

There is a quirk in atlantic HW to enable correct processing of
0xffff incorrect csum. Enable it.

The visible bug is that windows link partner with software generated csums
caused TCP connection to be unstable since all packets that csum value
are dropped.

Reported-by: Dmitry Bezrukov <dmitry.bezrukov@aquantia.com>
Signed-off-by: Nikita Danilov <ndanilov@aquantia.com>
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c

index e979f227cf0b3da2484db33402c3edc47fee8725..5c3065bdfddf3464dd42d182b98e12ec79f195ef 100644 (file)
@@ -266,12 +266,11 @@ static int hw_atl_b0_hw_offload_set(struct aq_hw_s *self,
                 */
                hw_atl_rpo_lro_max_coalescing_interval_set(self, 50);
 
-
                hw_atl_rpo_lro_qsessions_lim_set(self, 1U);
 
                hw_atl_rpo_lro_total_desc_lim_set(self, 2U);
 
-               hw_atl_rpo_lro_patch_optimization_en_set(self, 0U);
+               hw_atl_rpo_lro_patch_optimization_en_set(self, 1U);
 
                hw_atl_rpo_lro_min_pay_of_first_pkt_set(self, 10U);