[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7f19ab59f1bbfe74cf3d056ccd9adf556cd09f60.camel@mellanox.com>
Date: Wed, 31 Oct 2018 21:05:12 +0000
From: Saeed Mahameed <saeedm@...lanox.com>
To: "eric.dumazet@...il.com" <eric.dumazet@...il.com>,
"xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>
CC: "pstaszewski@...are.pl" <pstaszewski@...are.pl>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"dmichail@...gle.com" <dmichail@...gle.com>
Subject: Re: Latest net-next kernel 4.19.0+
On Tue, 2018-10-30 at 10:32 -0700, Cong Wang wrote:
> On Tue, Oct 30, 2018 at 7:16 AM Eric Dumazet <eric.dumazet@...il.com>
> wrote:
> >
> >
> >
> > On 10/30/2018 01:09 AM, Paweł Staszewski wrote:
> > >
> > >
> > > W dniu 30.10.2018 o 08:29, Eric Dumazet pisze:
> > > >
> > > > On 10/29/2018 11:09 PM, Dimitris Michailidis wrote:
> > > >
> > > > > Indeed this is a bug. I would expect it to produce frequent
> > > > > errors
> > > > > though as many odd-length
> > > > > packets would trigger it. Do you have RXFCS? Regardless, how
> > > > > frequently do you see the problem?
> > > > >
> > > >
> > > > Old kernels (before 88078d98d1bb) were simply resetting
> > > > ip_summed to CHECKSUM_NONE
> > > >
> > > > And before your fix (commit d55bef5059dd057bd), mlx5 bug was
> > > > canceling the bug you fixed.
> > > >
> > > > So we now need to also fix mlx5.
> > > >
> > > > And of course use skb_header_pointer() in mlx5e_get_fcs() as I
> > > > mentioned earlier,
> > > > plus __get_unaligned_cpu32() as you hinted.
> > > >
> > > >
> > > >
> > > >
> > >
> > > No RXFCS
>
>
> Same with Pawel, RXFCS is disabled by default.
>
>
> > >
> > > And this trace is rly frequently like once per 3/4 seconds
> > > like below:
> > > [28965.776864] vlan1490: hw csum failure
> >
> > Might be vlan related.
>
Hi Pawel, is the vlan stripping offload disabled or enabled in your
case ?
To verify:
ethtool -k <interface> | grep rx-vlan-offload
rx-vlan-offload: on
To set:
ethtool -K <interface> rxvlan on/off
if the vlan offload is off then it will trigger the mlx5e vlan csum
adjustment code pointed out by Eric.
Anyhow, it should work in both cases, but i am trying to narrow down
the possibilities.
Also could it be a double tagged packet ?
> Unlike Pawel's case, we don't use vlan at all, maybe this is why we
> see
> it much less frequently than Pawel.
>
> Also, it is probably not specific to mlx5, as there is another report
> which
> is probably a non-mlx5 driver.
>
Cong, How often does this happen ? can you some how verify if the
problematic packet has extra end padding after the ip payload ?
It would be cool if we had a feature in kernel to store such SKB in
memory when such issue occurs, and let the user dump it later (via
tcpdump) and send the dump to the vendor for debug so we could just
replay and see what happens.
> Thanks.
Powered by blists - more mailing lists