From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cong Wang Subject: Re: [Patch net] net: invert the check of detecting hardware RX checksum fault Date: Fri, 16 Nov 2018 12:15:01 -0800 Message-ID: References: <20181115231602.18328-1-xiyou.wangcong@gmail.com> <20181116015242.wmm6mooubjnum7qv@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Herbert Xu , Linux Kernel Network Developers , Tom Herbert , Eric Dumazet , Saeed Mahameed To: Eric Dumazet Return-path: Received: from mail-pf1-f196.google.com ([209.85.210.196]:41896 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725824AbeKQG3E (ORCPT ); Sat, 17 Nov 2018 01:29:04 -0500 Received: by mail-pf1-f196.google.com with SMTP id e22-v6so11894561pfn.8 for ; Fri, 16 Nov 2018 12:15:13 -0800 (PST) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Thu, Nov 15, 2018 at 8:52 PM Eric Dumazet wrote: > > It is very possible NIC provides an incorrect CHECKSUM_COMPLETE, in the > case non zero trailer bytes were added by a buggy switch (or host) > > Saeed can comment/confirm, but the theory is that the NIC does header analysis and > computes a checksum only on the bytes of the IP frame, not including the tail bytes > that were added by a switch. This theory seems can't explain why Pawel saw this warning so often, which is beyond the probability of a buggy switch. I don't know. > > You could use trafgen to cook such a frame and confirm the theory. > > Something like : I will try it. Thanks.