similar to: [PATCH net-next] virtio-net: don't do header check for dodgy gso packets

There's no need to do header check for virtio-net since: - Host sets dodgy for all gso packets from guest and check the header. - Host should be prepared for all kinds of evil packets from guest, since malicious guest can send any kinds of packet. So this patch sets NETIF_F_GSO_ROBUST for virtio-net to skip the check. Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: Michael S.

There's no need to do header check for virtio-net since: - Host sets dodgy for all gso packets from guest and check the header. - Host should be prepared for all kinds of evil packets from guest, since malicious guest can send any kinds of packet. So this patch sets NETIF_F_GSO_ROBUST for virtio-net to skip the check. Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: Michael S.

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 reverts commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4. Now that we've split UFO into v4 and v6 version, we can turn back UFO support for ipv4. Full IPv6 support will come later as it requires extending vnet header structure. Any older VM that assumes IPv6 support is included in UFO will continue to use UFO and the host will generate fragment ids for it, thus preserving connectivity.

This reverts commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4. Now that we've split UFO into v4 and v6 version, we can turn back UFO support for ipv4. Full IPv6 support will come later as it requires extending vnet header structure. Any older VM that assumes IPv6 support is included in UFO will continue to use UFO and the host will generate fragment ids for it, thus preserving connectivity.

Now that we have SCTP offload capabilities in the kernel, we can add them to virtio as well. First step is SCTP checksum. We need a new freature in virtio to negotiate this support since SCTP is excluded with the stardard checksum and requires a little bit extra. This series proposes VIRTIO_NET_F_SCTP_CSUM feature bit. As the "little bit extra", the kernel uses a new bit in the skb

Now that we have SCTP offload capabilities in the kernel, we can add them to virtio as well. First step is SCTP checksum. We need a new freature in virtio to negotiate this support since SCTP is excluded with the stardard checksum and requires a little bit extra. This series proposes VIRTIO_NET_F_SCTP_CSUM feature bit. As the "little bit extra", the kernel uses a new bit in the skb

Signed-off-by: Micha? Miros?aw <mirq-linux at rere.qmqm.pl> --- drivers/net/virtio_net.c | 46 +++++++++++++++++++--------------------------- 1 files changed, 19 insertions(+), 27 deletions(-) This is an example conversion to hw_features when constraints are constant and can be detected at init time. Build tested only. diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c

Signed-off-by: Micha? Miros?aw <mirq-linux at rere.qmqm.pl> --- drivers/net/virtio_net.c | 46 +++++++++++++++++++--------------------------- 1 files changed, 19 insertions(+), 27 deletions(-) This is an example conversion to hw_features when constraints are constant and can be detected at init time. Build tested only. diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c

This reverts commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4. Now that UFO functionality can correctly track the fragment id has been selected and select a fragment id if necessary, we can re-enable UFO on tap/macvap and virtio devices. Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> --- drivers/net/macvtap.c | 13 ++++++++----- drivers/net/tun.c | 19

This reverts commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4. Now that UFO functionality can correctly track the fragment id has been selected and select a fragment id if necessary, we can re-enable UFO on tap/macvap and virtio devices. Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> --- drivers/net/macvtap.c | 13 ++++++++----- drivers/net/tun.c | 19

This reverts commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4. Now that GSO functionality can correctly track if the fragment id has been selected and select a fragment id if necessary, we can re-enable UFO on tap/macvap and virtio devices. Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> --- drivers/net/macvtap.c | 13 ++++++++----- drivers/net/tun.c | 19

This reverts commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4. Now that GSO functionality can correctly track if the fragment id has been selected and select a fragment id if necessary, we can re-enable UFO on tap/macvap and virtio devices. Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> --- drivers/net/macvtap.c | 13 ++++++++----- drivers/net/tun.c | 19

Now that we have SCTP offload capabilities in the kernel, we can add them to virtio as well. First step is SCTP checksum. We need a new freature in virtio to negotiate this support since SCTP is excluded with the stardard checksum and requires a little bit extra. This series proposes VIRTIO_NET_F_SCTP_CSUM feature bit. As the "little bit extra", the kernel uses a new bit in the skb

The virtio net protocol supports UFO but does not provide for passing a fragment ID for fragmentation of IPv6 packets. We used to generate a fragment ID wherever such a packet was fragmented, but currently we always use ID=0! v2: Add blank lines after declarations Ben. Ben Hutchings (2): drivers/net: Disable UFO through virtio drivers/net,ipv6: Select IPv6 fragment idents for virtio UFO

The virtio net protocol supports UFO but does not provide for passing a fragment ID for fragmentation of IPv6 packets. We used to generate a fragment ID wherever such a packet was fragmented, but currently we always use ID=0! v2: Add blank lines after declarations Ben. Ben Hutchings (2): drivers/net: Disable UFO through virtio drivers/net,ipv6: Select IPv6 fragment idents for virtio UFO

IPv6 does not allow fragmentation by routers, so there is no fragmentation ID in the fixed header. UFO for IPv6 requires the ID to be passed separately, but there is no provision for this in the virtio net protocol. Until recently our software implementation of UFO/IPv6 generated a new ID, but this was a bug. Now we will use ID=0 for any UFO/IPv6 packet passed through a tap, which is even

IPv6 does not allow fragmentation by routers, so there is no fragmentation ID in the fixed header. UFO for IPv6 requires the ID to be passed separately, but there is no provision for this in the virtio net protocol. Until recently our software implementation of UFO/IPv6 generated a new ID, but this was a bug. Now we will use ID=0 for any UFO/IPv6 packet passed through a tap, which is even

On Thu, Oct 30, 2014 at 06:27:12PM +0000, Ben Hutchings wrote: > IPv6 does not allow fragmentation by routers, so there is no > fragmentation ID in the fixed header. UFO for IPv6 requires the ID to > be passed separately, but there is no provision for this in the virtio > net protocol. > > Until recently our software implementation of UFO/IPv6 generated a new > ID, but this