On 17/05/19 (金) 18:53, Vlad Yasevich wrote:
On 05/19/2017 04:16 AM, Toshiaki Makita wrote:
On 2017/05/19 16:09, Vlad Yasevich wrote:
On 05/18/2017 10:13 PM, Toshiaki Makita wrote:
On 2017/05/18 22:31, Vladislav Yasevich wrote:
It appears that since commit 8cb65d000, Q-in-Q vlans have been
broken. The series that commit is part of enabled TSO and checksum
offloading on Q-in-Q vlans. However, most HW we support can't handle
it. To work around the issue, the above commit added a function that
turns off offloads on Q-in-Q devices, but it left the checksum offload.
That will cause issues with most older devices that supprort very basic
checksum offload capabilities as well as some newer devices (we've
reproduced te problem with both be2net and bnx).
To solve this for everyone, turn off checksum offloading feature
by default when sending Q-in-Q traffic. Devices that are proven to
work can provided a corrected ndo_features_check implemetation.
Fixes: 8cb65d000 ("net: Move check for multiple vlans to drivers")
CC: Toshiaki Makita <makita.toshi...@lab.ntt.co.jp>
Signed-off-by: Vladislav Yasevich <vyase...@redhat.com>
---
include/linux/if_vlan.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
index 8d5fcd6..ae537f0 100644
--- a/include/linux/if_vlan.h
+++ b/include/linux/if_vlan.h
@@ -619,7 +619,6 @@ static inline netdev_features_t vlan_features_check(const
struct sk_buff *skb,
NETIF_F_SG |
NETIF_F_HIGHDMA |
NETIF_F_FRAGLIST |
- NETIF_F_HW_CSUM |
NETIF_F_HW_VLAN_CTAG_TX |
NETIF_F_HW_VLAN_STAG_TX);
I guess HW_CSUM theoretically can handle Q-in-Q packets and the problem
is IP_CSUM and IPV6_CSUM.
So wouldn't it be better to leave HW_CSUM and drop IP_CSUM/IPV6_CSUM,
i.e. change intersection into bitwise AND?
It wasn't really a problem before accelerations got enabled on q-in-q
vlans.
Right for stacked vlan device.
But I think the check was there for packets from guests forwarded by
bridge to vlan device so it was a problem before 8cb65d000.
Not really, since stacked vlans in guests wouldn't have accelerations on.
Haven't really tried a new guest on old hosts. It might be an issue there...
It's real. I'm now remembering that I came across a similar issue before
introducing 8cb65d000. The situation was that bridge (vlan_filtering)
adds a vlan tag to a frame which is already tagged by guests, or by a
vlan device on the top of the bridge (Note that virtio and bridge have
HW_CSUM in vlan_features). I addressed the problem in drivers side since
all the IP/IPV6_CSUM drivers I encountered the issue on are able to
notify devices of IP header offset. Now I checked be2net driver's code
and realized it doesn't provide IP offset so it makes sense to drop
IP/IPV6_CSUM by default. Anyway, kernels before 8cb65d000 have that
problem, not only after 8cb65d000.
Toshiaki Makita
