From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Dumazet <edumazet@google.com>
Subject: Re: [Patch net] mlx5: fixup checksum for ethernet padding
Date: Tue, 27 Nov 2018 17:48:58 -0800
Message-ID: <CANn89iJx4t6seOhkBFyoGuDquZ_7J_oM+nmn+TK79H=YKfm4fQ@mail.gmail.com>
References: <20181127232142.7561-1-xiyou.wangcong@gmail.com>
 <0b5b3894-161f-c604-12bc-ecde341d7776@gmail.com> <CAM_iQpW2=rTa-QZxK5ygvr=UgM9Lcxr_NyPiD=1jh3Hgovn2gQ@mail.gmail.com>
 <0e6a8a08-b181-b17a-1330-0159808e9a42@gmail.com> <CAM_iQpWc82LG4b40XZCypP+SFYX9LCm2GCaMaG_xfU87h7SOow@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
        netdev <netdev@vger.kernel.org>,
        Saeed Mahameed <saeedm@mellanox.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-io1-f65.google.com ([209.85.166.65]:37345 "EHLO
        mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1726548AbeK1MtC (ORCPT
        <rfc822;netdev@vger.kernel.org>); Wed, 28 Nov 2018 07:49:02 -0500
Received: by mail-io1-f65.google.com with SMTP id a3so18673271ioc.4
        for <netdev@vger.kernel.org>; Tue, 27 Nov 2018 17:49:11 -0800 (PST)
In-Reply-To: <CAM_iQpWc82LG4b40XZCypP+SFYX9LCm2GCaMaG_xfU87h7SOow@mail.gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Tue, Nov 27, 2018 at 5:42 PM Cong Wang <xiyou.wangcong@gmail.com> wrote:
>
> On Tue, Nov 27, 2018 at 5:25 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> >
> >
> > On 11/27/2018 04:07 PM, Cong Wang wrote:
> > > On Tue, Nov 27, 2018 at 3:48 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > >>
> > >> But the padding might be added on normal packets (say 1000 bytes + 3 bytes of padding) ?
> > >
> > > I never see other padding cases than ETH_ZLEN. Does ethernet standard
> > > require padding for other cases? I only read the section "3.2.8 Pad field" in
> > > the standard.
> > >
> >
> > Padding can be done by senders, eg using AF_PACKET,
> > added at the tail of a regular IP/IP6 frame of 1000 or 6000 bytes.
>
>
> I tried the trafgen script you provided, it doesn't trigger any checksum fault.
> So, it is probably a different case.

As I said, you need to cook a packet that the NIC is not able to L4
checksum-verify.

Maybe an encapsulated packet could do the trick, but only Mellanox
experts can say.

>
> >
> > Note that mlx5 will presumably set CHECKSUM_UNNECESSARY for standard protocols,
> > so if you want to reproduce the issue, you might need to find an IP frame that
> > mlx5 is not able to checksum validate.
>
> This warning is 100% reproducible with a TCP RST packet (no data)
> here, after I find the right switch which pads non-zero's. This is
> also how I verified this patch.

Sure this patch handles short frames, but I am saying the issue is
more generic than that.