On Tue, 2018-10-30 at 10:32 -0700, Cong Wang wrote: > On Tue, Oct 30, 2018 at 7:16 AM Eric Dumazet <eric.duma...@gmail.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.
