From: David S. Miller Date: Wed, 4 Feb 2015 07:06:49 +0000 (-0800) Subject: Merge branch 'virtio_net_ufo' X-Git-Tag: v3.19~12^2~14 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=4c122f4cbf80fa35b7b8508b6e117f1e8cd1fddb;p=platform%2Fkernel%2Flinux-exynos.git Merge branch 'virtio_net_ufo' Vladislav Yasevich says: ==================== Restore UFO support to virtio_net devices commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 Author: Ben Hutchings Date: Thu Oct 30 18:27:12 2014 +0000 drivers/net: Disable UFO through virtio Turned off UFO support to virtio-net based devices due to issues with IPv6 fragment id generation for UFO packets. The issue was that IPv6 UFO/GSO implementation expects the fragment id to be supplied in skb_shinfo(). However, for packets generated by the VMs, the fragment id is not supplied which causes all IPv6 fragments to have the id of 0. The problem is that turning off UFO support on tap/macvtap as well as virtio devices caused issues with migrations. Migrations would fail when moving a vm from a kernel supporting expecting UFO to work to the newer kernels that disabled UFO. This series provides a partial solution to address the migration issue. The series allows us to track whether skb_shinfo()->ip6_frag_id has been set by treating value of 0 as unset. This lets GSO code to generate fragment ids if they are necessary (ex: packet was generated by VM or packet socket). Since v3: - Resolved build issue when IPv6 is a module. - Removed trailing white space. Since v2: - Rebase and rebuild to make sure everything works. No changes to the patches were done. Since v1: - Removed the skb bit and use value of 0 as tracker. - Used Eric's suggestion to set fragment id as 0x80000000 if id generation procedure yeilded a 0 result. - Consolidated ipv6 id genration code. ==================== Signed-off-by: David S. Miller --- 4c122f4cbf80fa35b7b8508b6e117f1e8cd1fddb