similar to: [PATCH net-next 0/5] virtio-net: Add SCTP checksum offload support

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

On Mon, Apr 02, 2018 at 09:40:02AM -0400, Vladislav Yasevich wrote: > To support SCTP checksum offloading, we need to add a new feature > to virtio_net, so we can negotiate support between the hypervisor > and the guest. > > The signalling to the guest that an alternate checksum needs to > be used is done via a new flag in the virtio_net_hdr. If the > flag is set, the host

On Mon, Apr 02, 2018 at 09:40:02AM -0400, Vladislav Yasevich wrote: > To support SCTP checksum offloading, we need to add a new feature > to virtio_net, so we can negotiate support between the hypervisor > and the guest. > > The signalling to the guest that an alternate checksum needs to > be used is done via a new flag in the virtio_net_hdr. If the > flag is set, the host

On Mon, Apr 16, 2018 at 09:45:48AM -0400, Vlad Yasevich wrote: > On 04/11/2018 06:49 PM, Michael S. Tsirkin wrote: > > On Mon, Apr 02, 2018 at 09:40:02AM -0400, Vladislav Yasevich wrote: > >> To support SCTP checksum offloading, we need to add a new feature > >> to virtio_net, so we can negotiate support between the hypervisor > >> and the guest. > >>

On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > Since we now have support for software CRC32c offload, turn it on > for macvlan and macvtap devices so that guests can take advantage > of offload SCTP checksums to the host or host hardware. > > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- > drivers/net/macvlan.c | 5 +++-- >

On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > Since we now have support for software CRC32c offload, turn it on > for macvlan and macvtap devices so that guests can take advantage > of offload SCTP checksums to the host or host hardware. > > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- > drivers/net/macvlan.c | 5 +++-- >

On Wed, May 02, 2018 at 09:27:00AM -0400, Vlad Yasevich wrote: > On 05/01/2018 11:24 PM, Michael S. Tsirkin wrote: > > On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > >> Since we now have support for software CRC32c offload, turn it on > >> for macvlan and macvtap devices so that guests can take advantage > >> of offload SCTP checksums to

On Wed, May 02, 2018 at 09:27:00AM -0400, Vlad Yasevich wrote: > On 05/01/2018 11:24 PM, Michael S. Tsirkin wrote: > > On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > >> Since we now have support for software CRC32c offload, turn it on > >> for macvlan and macvtap devices so that guests can take advantage > >> of offload SCTP checksums to

On Wed, May 02, 2018 at 10:00:14AM -0400, Vlad Yasevich wrote: > On 05/02/2018 09:46 AM, Michael S. Tsirkin wrote: > > On Wed, May 02, 2018 at 09:27:00AM -0400, Vlad Yasevich wrote: > >> On 05/01/2018 11:24 PM, Michael S. Tsirkin wrote: > >>> On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > >>>> Since we now have support for

On 04/11/2018 06:49 PM, Michael S. Tsirkin wrote: > On Mon, Apr 02, 2018 at 09:40:02AM -0400, Vladislav Yasevich wrote: >> To support SCTP checksum offloading, we need to add a new feature >> to virtio_net, so we can negotiate support between the hypervisor >> and the guest. >> >> The signalling to the guest that an alternate checksum needs to >> be used is

To support SCTP checksum offloading, we need to add a new feature to virtio_net, so we can negotiate support between the hypervisor and the guest. The signalling to the guest that an alternate checksum needs to be used is done via a new flag in the virtio_net_hdr. If the flag is set, the host will know to perform an alternate checksum calculation, which right now is only CRC32c. Signed-off-by:

On Wed, May 02, 2018 at 11:14:13AM -0300, Marcelo Ricardo Leitner wrote: > On Wed, May 02, 2018 at 06:16:45AM +0300, Michael S. Tsirkin wrote: > > On Tue, May 01, 2018 at 10:07:34PM -0400, Vladislav Yasevich wrote: > > > To support SCTP checksum offloading, we need to add a new feature > > > to virtio_net, so we can negotiate support between the hypervisor > > >

On Wed, Dec 17, 2014 at 01:20:46PM -0500, Vladislav Yasevich wrote: > Split IPv6 support for UFO into its own feature similiar to TSO. > This will later allow us to re-enable UFO support for virtio-net > devices. > > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- > include/linux/netdev_features.h | 7 +++++-- > include/linux/netdevice.h | 1

On Wed, Dec 17, 2014 at 01:20:46PM -0500, Vladislav Yasevich wrote: > Split IPv6 support for UFO into its own feature similiar to TSO. > This will later allow us to re-enable UFO support for virtio-net > devices. > > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- > include/linux/netdev_features.h | 7 +++++-- > include/linux/netdevice.h | 1

To support SCTP checksum offloading, we need to add a new feature to virtio_net, so we can negotiate support between the hypervisor and the guest. The HOST feature bit signifies offloading support for transmit and enables device offload features. The GUEST feature bit signifies offloading support of recieve and is currently only used by the driver in case of xdp. That patch also adds an

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

Cc Dave, pls remember to do this next time otherwise your patches won't get merged :) On Wed, Dec 17, 2014 at 06:31:50PM -0500, Vlad Yasevich wrote: > On 12/17/2014 05:45 PM, Michael S. Tsirkin wrote: > > On Wed, Dec 17, 2014 at 01:20:46PM -0500, Vladislav Yasevich wrote: > >> Split IPv6 support for UFO into its own feature similiar to TSO. > >> This will later

Cc Dave, pls remember to do this next time otherwise your patches won't get merged :) On Wed, Dec 17, 2014 at 06:31:50PM -0500, Vlad Yasevich wrote: > On 12/17/2014 05:45 PM, Michael S. Tsirkin wrote: > > On Wed, Dec 17, 2014 at 01:20:46PM -0500, Vladislav Yasevich wrote: > >> Split IPv6 support for UFO into its own feature similiar to TSO. > >> This will later