On Tue, Nov 27, 2018 at 5:42 PM Cong Wang <xiyou.wangc...@gmail.com> wrote: > > On Tue, Nov 27, 2018 at 5:25 PM Eric Dumazet <eric.duma...@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.duma...@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.
