search for: ufov6

...el fails. > > > > This series eliminate the ambiguous NETIF_F_UFO. > > But VIRTIO_NET_F_{HOST|GUEST}_UFO and VIRTIO_NET_F_HDR_GSO_UDP is still > ambigious. I know it was used to keep compatibility for legacy guest. But > what's the future plan? Differentiate UFOv4 and UFOv6 in virtio features and > gso type in vnet header looks sufficient? [...] The IPv6 fragmentation ID needs to be added to the vnet header, to do UFOv6 properly. If it wasn't for that lack, we wouldn't have to split the feature flag. Ben. -- Ben Hutchings If more than one person is res...

...el fails. > > > > This series eliminate the ambiguous NETIF_F_UFO. > > But VIRTIO_NET_F_{HOST|GUEST}_UFO and VIRTIO_NET_F_HDR_GSO_UDP is still > ambigious. I know it was used to keep compatibility for legacy guest. But > what's the future plan? Differentiate UFOv4 and UFOv6 in virtio features and > gso type in vnet header looks sufficient? [...] The IPv6 fragmentation ID needs to be added to the vnet header, to do UFOv6 properly. If it wasn't for that lack, we wouldn't have to split the feature flag. Ben. -- Ben Hutchings If more than one person is res...

...biguous NETIF_F_UFO. >> > >> > But VIRTIO_NET_F_{HOST|GUEST}_UFO and VIRTIO_NET_F_HDR_GSO_UDP is >> still >> > ambigious. I know it was used to keep compatibility for legacy >> guest. But >> > what's the future plan? Differentiate UFOv4 and UFOv6 in virtio >> features and >> > gso type in vnet header looks sufficient? >> [...] >> >> The IPv6 fragmentation ID needs to be added to the vnet header, to >> do >> UFOv6 properly. If it wasn't for that lack, we wouldn't have to >>...

...biguous NETIF_F_UFO. >> > >> > But VIRTIO_NET_F_{HOST|GUEST}_UFO and VIRTIO_NET_F_HDR_GSO_UDP is >> still >> > ambigious. I know it was used to keep compatibility for legacy >> guest. But >> > what's the future plan? Differentiate UFOv4 and UFOv6 in virtio >> features and >> > gso type in vnet header looks sufficient? >> [...] >> >> The IPv6 fragmentation ID needs to be added to the vnet header, to >> do >> UFOv6 properly. If it wasn't for that lack, we wouldn't have to >>...

...k, migrating a guest to a 3.18 kernel fails. > This series eliminate the ambiguous NETIF_F_UFO. But VIRTIO_NET_F_{HOST|GUEST}_UFO and VIRTIO_NET_F_HDR_GSO_UDP is still ambigious. I know it was used to keep compatibility for legacy guest. But what's the future plan? Differentiate UFOv4 and UFOv6 in virtio features and gso type in vnet header looks sufficient? With the series, we can't send UFOv6 packet but legacy guest can. How about fix the UFOv6 also in this series? Thanks > Vladislav Yasevich (10): > core: Split out UFO6 support > net: Correctly mark IPv6 UFO offload...

...k, migrating a guest to a 3.18 kernel fails. > This series eliminate the ambiguous NETIF_F_UFO. But VIRTIO_NET_F_{HOST|GUEST}_UFO and VIRTIO_NET_F_HDR_GSO_UDP is still ambigious. I know it was used to keep compatibility for legacy guest. But what's the future plan? Differentiate UFOv4 and UFOv6 in virtio features and gso type in vnet header looks sufficient? With the series, we can't send UFOv6 packet but legacy guest can. How about fix the UFOv6 also in this series? Thanks > Vladislav Yasevich (10): > core: Split out UFO6 support > net: Correctly mark IPv6 UFO offload...

...> > This series eliminate the ambiguous NETIF_F_UFO. > > > > But VIRTIO_NET_F_{HOST|GUEST}_UFO and VIRTIO_NET_F_HDR_GSO_UDP is still > > ambigious. I know it was used to keep compatibility for legacy guest. But > > what's the future plan? Differentiate UFOv4 and UFOv6 in virtio features and > > gso type in vnet header looks sufficient? > [...] > > The IPv6 fragmentation ID needs to be added to the vnet header, to do > UFOv6 properly. If it wasn't for that lack, we wouldn't have to split > the feature flag. > > Ben. Right....

...> > This series eliminate the ambiguous NETIF_F_UFO. > > > > But VIRTIO_NET_F_{HOST|GUEST}_UFO and VIRTIO_NET_F_HDR_GSO_UDP is still > > ambigious. I know it was used to keep compatibility for legacy guest. But > > what's the future plan? Differentiate UFOv4 and UFOv6 in virtio features and > > gso type in vnet header looks sufficient? > [...] > > The IPv6 fragmentation ID needs to be added to the vnet header, to do > UFOv6 properly. If it wasn't for that lack, we wouldn't have to split > the feature flag. > > Ben. Right....

...NETIF_F_UFO. > >> > > But VIRTIO_NET_F_{HOST|GUEST}_UFO and VIRTIO_NET_F_HDR_GSO_UDP is > >>still > >> > ambigious. I know it was used to keep compatibility for legacy guest. > >>But > >> > what's the future plan? Differentiate UFOv4 and UFOv6 in virtio > >>features and > >> > gso type in vnet header looks sufficient? > >> [...] > >> The IPv6 fragmentation ID needs to be added to the vnet header, to do > >> UFOv6 properly. If it wasn't for that lack, we wouldn't have to split &gt...

...NETIF_F_UFO. > >> > > But VIRTIO_NET_F_{HOST|GUEST}_UFO and VIRTIO_NET_F_HDR_GSO_UDP is > >>still > >> > ambigious. I know it was used to keep compatibility for legacy guest. > >>But > >> > what's the future plan? Differentiate UFOv4 and UFOv6 in virtio > >>features and > >> > gso type in vnet header looks sufficient? > >> [...] > >> The IPv6 fragmentation ID needs to be added to the vnet header, to do > >> UFOv6 properly. If it wasn't for that lack, we wouldn't have to split &gt...

...xe and also for stable. > + /* This allows legacy application to work. > + * Do not change the gso_type as it may > + * not be upderstood by legacy applications. > + */ Isn't this an issue that we use SKB_GSO_UDP for a UDPv6 packet? Especially consider we want to fix UFOv6 in the future? We probably can use SKB_GSO_UDP6 here and try to fix it in tun_put_user() if a legacy userspace is detected. > ipv6_proxy_select_ident(skb); Question still for vlan, is network header correctly set here? Looks like ipv6_proxy_select_ident() depends on correct network header...

...xe and also for stable. > + /* This allows legacy application to work. > + * Do not change the gso_type as it may > + * not be upderstood by legacy applications. > + */ Isn't this an issue that we use SKB_GSO_UDP for a UDPv6 packet? Especially consider we want to fix UFOv6 in the future? We probably can use SKB_GSO_UDP6 here and try to fix it in tun_put_user() if a legacy userspace is detected. > ipv6_proxy_select_ident(skb); Question still for vlan, is network header correctly set here? Looks like ipv6_proxy_select_ident() depends on correct network header...

UFO support in the kernel applies to both IPv4 and IPv6 protocols with the same device feature. However some devices may not be able to support one of the offloads. For this we split the UFO offload feature into 2 pieces. NETIF_F_UFO now controlls the IPv4 part and this series introduces NETIF_F_UFO6. As a result of this work, we can now re-enable NETIF_F_UFO on virtio_net devices and restore

UFO support in the kernel applies to both IPv4 and IPv6 protocols with the same device feature. However some devices may not be able to support one of the offloads. For this we split the UFO offload feature into 2 pieces. NETIF_F_UFO now controlls the IPv4 part and this series introduces NETIF_F_UFO6. As a result of this work, we can now re-enable NETIF_F_UFO on virtio_net devices and restore

...; + /* This allows legacy application to work. >> + * Do not change the gso_type as it may >> + * not be upderstood by legacy applications. >> + */ > > Isn't this an issue that we use SKB_GSO_UDP for a UDPv6 packet? Especially > consider we want to fix UFOv6 in the future? We probably can use > SKB_GSO_UDP6 here and try to fix it in tun_put_user() if a legacy userspace > is detected. There is a slight problem with this. This will force fragmentation of IPv6 traffic between VMs since UFO6 wouldn't be enabled on a destination device. So, sudd...

...; + /* This allows legacy application to work. >> + * Do not change the gso_type as it may >> + * not be upderstood by legacy applications. >> + */ > > Isn't this an issue that we use SKB_GSO_UDP for a UDPv6 packet? Especially > consider we want to fix UFOv6 in the future? We probably can use > SKB_GSO_UDP6 here and try to fix it in tun_put_user() if a legacy userspace > is detected. There is a slight problem with this. This will force fragmentation of IPv6 traffic between VMs since UFO6 wouldn't be enabled on a destination device. So, sudd...