[virtio-dev] Re: [PATCH V2 net-next 1/6] virtio: Add support for SCTP checksum offloading

[virtio-dev] Re: [PATCH V2 net-next 1/6] virtio: Add support for SCTP checksum offloading

[Michael S. Tsirkin]

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
> 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 addition virtio_net header flag which
> mirrors the skb->csum_not_inet flag.  This flags is used to indicate
> that is this an SCTP packet that needs its checksum computed by the
> lower layer.  In this case, the lower layer is the host hypervisor or
> possibly HW nic that supporst CRC32c offload.
> 
> In the case that GUEST feature bit is flag, it will be possible to
> receive a virtio_net header with this bit set, which will set the
> corresponding skb bit.  SCTP protocol will be updated to correctly
> deal with it.
> 
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> ---
>  drivers/net/virtio_net.c        | 14 +++++++++++++-
>  include/linux/virtio_net.h      |  6 ++++++
>  include/uapi/linux/virtio_net.h |  5 +++++
>  3 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 7b187ec..34af280 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -2148,6 +2148,8 @@ static int virtnet_clear_guest_offloads(struct virtnet_info *vi)
>  
>  	if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_CSUM))
>  		offloads = 1ULL << VIRTIO_NET_F_GUEST_CSUM;
> +	if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_SCTP_CSUM))
> +		offloads |= 1ULL << VIRTIO_NET_F_GUEST_SCTP_CSUM;
>  
>  	return virtnet_set_guest_offloads(vi, offloads);
>  }
> @@ -2160,6 +2162,8 @@ static int virtnet_restore_guest_offloads(struct virtnet_info *vi)
>  		return 0;
>  	if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_CSUM))
>  		offloads |= 1ULL << VIRTIO_NET_F_GUEST_CSUM;
> +	if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_SCTP_CSUM))
> +		offloads |= 1ULL << VIRTIO_NET_F_GUEST_SCTP_CSUM;
>  
>  	return virtnet_set_guest_offloads(vi, offloads);
>  }
> @@ -2724,6 +2728,7 @@ static int virtnet_probe(struct virtio_device *vdev)
>  	/* Do we support "hardware" checksums? */
>  	if (virtio_has_feature(vdev, VIRTIO_NET_F_CSUM)) {
>  		/* This opens up the world of extra features. */
> +
>  		dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_SG;
>  		if (csum)
>  			dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG;
> @@ -2746,9 +2751,15 @@ static int virtnet_probe(struct virtio_device *vdev)
>  			dev->features |= dev->hw_features & NETIF_F_ALL_TSO;
>  		/* (!csum && gso) case will be fixed by register_netdev() */
>  	}
> +
>  	if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_CSUM))
>  		dev->features |= NETIF_F_RXCSUM;
>  
> +	if (virtio_has_feature(vdev, VIRTIO_NET_F_HOST_SCTP_CSUM)) {
> +		dev->hw_features |= NETIF_F_SCTP_CRC;
> +		dev->features |= NETIF_F_SCTP_CRC;
> +	}
> +
>  	dev->vlan_features = dev->features;
>  
>  	/* MTU range: 68 - 65535 */
> @@ -2962,7 +2973,8 @@ static struct virtio_device_id id_table[] = {
>  	VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ, \
>  	VIRTIO_NET_F_CTRL_MAC_ADDR, \
>  	VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS, \
> -	VIRTIO_NET_F_SPEED_DUPLEX
> +	VIRTIO_NET_F_SPEED_DUPLEX, \
> +	VIRTIO_NET_F_HOST_SCTP_CSUM, VIRTIO_NET_F_GUEST_SCTP_CSUM
>  
>  static unsigned int features[] = {
>  	VIRTNET_FEATURES,
> diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> index f144216..28fffdc 100644
> --- a/include/linux/virtio_net.h
> +++ b/include/linux/virtio_net.h
> @@ -39,6 +39,9 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
>  
>  		if (!skb_partial_csum_set(skb, start, off))
>  			return -EINVAL;
> +
> +		if (hdr->flags & VIRTIO_NET_HDR_F_CSUM_NOT_INET)
> +			skb->csum_not_inet = 1;
>  	}
>  
>  	if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
> @@ -91,6 +94,9 @@ static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
>  				skb_checksum_start_offset(skb));
>  		hdr->csum_offset = __cpu_to_virtio16(little_endian,
>  				skb->csum_offset);
> +
> +		if (skb->csum_not_inet)
> +			hdr->flags |= VIRTIO_NET_HDR_F_CSUM_NOT_INET;
>  	} else if (has_data_valid &&
>  		   skb->ip_summed == CHECKSUM_UNNECESSARY) {
>  		hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
> diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
> index 5de6ed3..9dfca1a 100644
> --- a/include/uapi/linux/virtio_net.h
> +++ b/include/uapi/linux/virtio_net.h
> @@ -57,6 +57,10 @@
>  					 * Steering */
>  #define VIRTIO_NET_F_CTRL_MAC_ADDR 23	/* Set MAC address */
>  
> +#define VIRTIO_NET_F_GUEST_SCTP_CSUM  61 /* Guest handles SCTP pks w/ partial
> +					  * csum */
> +#define VIRTIO_NET_F_HOST_SCTP_CSUM   62 /* HOST handles SCTP pkts w/ partial
> +					  * csum */
>  #define VIRTIO_NET_F_SPEED_DUPLEX 63	/* Device set linkspeed and duplex */
>  
>  #ifndef VIRTIO_NET_NO_LEGACY
> @@ -101,6 +105,7 @@ struct virtio_net_config {
>  struct virtio_net_hdr_v1 {
>  #define VIRTIO_NET_HDR_F_NEEDS_CSUM	1	/* Use csum_start, csum_offset */
>  #define VIRTIO_NET_HDR_F_DATA_VALID	2	/* Csum is valid */
> +#define VIRTIO_NET_HDR_F_CSUM_NOT_INET  4       /* Checksum is not inet */

Both comment and name are not very informative.
How about just saying CRC32c ?

>  	__u8 flags;
>  #define VIRTIO_NET_HDR_GSO_NONE		0	/* Not a GSO frame */
>  #define VIRTIO_NET_HDR_GSO_TCPV4	1	/* GSO frame, IPv4 TCP (TSO) */
> -- 
> 2.9.5

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: [PATCH V2 net-next 5/6] macvlan/macvtap: Add support for SCTP checksum offload.

[Michael S. Tsirkin]

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@redhat.com>
> ---
>  drivers/net/macvlan.c | 5 +++--
>  drivers/net/tap.c     | 8 +++++---
>  2 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> index 725f4b4..646b730 100644
> --- a/drivers/net/macvlan.c
> +++ b/drivers/net/macvlan.c
> @@ -834,7 +834,7 @@ static struct lock_class_key macvlan_netdev_addr_lock_key;
>  
>  #define ALWAYS_ON_OFFLOADS \
>  	(NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_GSO_SOFTWARE | \
> -	 NETIF_F_GSO_ROBUST | NETIF_F_GSO_ENCAP_ALL)
> +	 NETIF_F_GSO_ROBUST | NETIF_F_GSO_ENCAP_ALL | NETIF_F_SCTP_CRC)
>  
>  #define ALWAYS_ON_FEATURES (ALWAYS_ON_OFFLOADS | NETIF_F_LLTX)
>  
> @@ -842,7 +842,8 @@ static struct lock_class_key macvlan_netdev_addr_lock_key;
>  	(NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST | \
>  	 NETIF_F_GSO | NETIF_F_TSO | NETIF_F_LRO | \
>  	 NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_GRO | NETIF_F_RXCSUM | \
> -	 NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER)
> +	 NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER | \
> +	 NETIF_F_SCTP_CRC)
>  
>  #define MACVLAN_STATE_MASK \
>  	((1<<__LINK_STATE_NOCARRIER) | (1<<__LINK_STATE_DORMANT))
> diff --git a/drivers/net/tap.c b/drivers/net/tap.c
> index 9b6cb78..2c8512b 100644
> --- a/drivers/net/tap.c
> +++ b/drivers/net/tap.c
> @@ -369,8 +369,7 @@ rx_handler_result_t tap_handle_frame(struct sk_buff **pskb)
>  		 *	  check, we either support them all or none.
>  		 */
>  		if (skb->ip_summed == CHECKSUM_PARTIAL &&
> -		    !(features & NETIF_F_CSUM_MASK) &&
> -		    skb_checksum_help(skb))
> +		    skb_csum_hwoffload_help(skb, features))
>  			goto drop;
>  		if (ptr_ring_produce(&q->ring, skb))
>  			goto drop;
> @@ -945,6 +944,9 @@ static int set_offload(struct tap_queue *q, unsigned long arg)
>  		}
>  	}
>  
> +	if (arg & TUN_F_SCTP_CSUM)
> +		feature_mask |= NETIF_F_SCTP_CRC;
> +

so this still affects TX, shouldn't this affect RX instead?


>  	/* tun/tap driver inverts the usage for TSO offloads, where
>  	 * setting the TSO bit means that the userspace wants to
>  	 * accept TSO frames and turning it off means that user space
> @@ -1077,7 +1079,7 @@ static long tap_ioctl(struct file *file, unsigned int cmd,
>  	case TUNSETOFFLOAD:
>  		/* let the user check for future flags */
>  		if (arg & ~(TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 |
> -			    TUN_F_TSO_ECN | TUN_F_UFO))
> +			    TUN_F_TSO_ECN | TUN_F_UFO | TUN_F_SCTP_CSUM))
>  			return -EINVAL;
>  
>  		rtnl_lock();
> -- 
> 2.9.5

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

Re: [virtio-dev] Re: [PATCH V2 net-next 1/6] virtio: Add support for SCTP checksum offloading

[Vlad Yasevich]

On 05/01/2018 11:16 PM, 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
>> 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 addition virtio_net header flag which
>> mirrors the skb->csum_not_inet flag.  This flags is used to indicate
>> that is this an SCTP packet that needs its checksum computed by the
>> lower layer.  In this case, the lower layer is the host hypervisor or
>> possibly HW nic that supporst CRC32c offload.
>>
>> In the case that GUEST feature bit is flag, it will be possible to
>> receive a virtio_net header with this bit set, which will set the
>> corresponding skb bit.  SCTP protocol will be updated to correctly
>> deal with it.
>>
>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
>> ---
>>  drivers/net/virtio_net.c        | 14 +++++++++++++-
>>  include/linux/virtio_net.h      |  6 ++++++
>>  include/uapi/linux/virtio_net.h |  5 +++++
>>  3 files changed, 24 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index 7b187ec..34af280 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -2148,6 +2148,8 @@ static int virtnet_clear_guest_offloads(struct virtnet_info *vi)
>>  
>>  	if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_CSUM))
>>  		offloads = 1ULL << VIRTIO_NET_F_GUEST_CSUM;
>> +	if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_SCTP_CSUM))
>> +		offloads |= 1ULL << VIRTIO_NET_F_GUEST_SCTP_CSUM;
>>  
>>  	return virtnet_set_guest_offloads(vi, offloads);
>>  }
>> @@ -2160,6 +2162,8 @@ static int virtnet_restore_guest_offloads(struct virtnet_info *vi)
>>  		return 0;
>>  	if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_CSUM))
>>  		offloads |= 1ULL << VIRTIO_NET_F_GUEST_CSUM;
>> +	if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_SCTP_CSUM))
>> +		offloads |= 1ULL << VIRTIO_NET_F_GUEST_SCTP_CSUM;
>>  
>>  	return virtnet_set_guest_offloads(vi, offloads);
>>  }
>> @@ -2724,6 +2728,7 @@ static int virtnet_probe(struct virtio_device *vdev)
>>  	/* Do we support "hardware" checksums? */
>>  	if (virtio_has_feature(vdev, VIRTIO_NET_F_CSUM)) {
>>  		/* This opens up the world of extra features. */
>> +
>>  		dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_SG;
>>  		if (csum)
>>  			dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG;
>> @@ -2746,9 +2751,15 @@ static int virtnet_probe(struct virtio_device *vdev)
>>  			dev->features |= dev->hw_features & NETIF_F_ALL_TSO;
>>  		/* (!csum && gso) case will be fixed by register_netdev() */
>>  	}
>> +
>>  	if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_CSUM))
>>  		dev->features |= NETIF_F_RXCSUM;
>>  
>> +	if (virtio_has_feature(vdev, VIRTIO_NET_F_HOST_SCTP_CSUM)) {
>> +		dev->hw_features |= NETIF_F_SCTP_CRC;
>> +		dev->features |= NETIF_F_SCTP_CRC;
>> +	}
>> +
>>  	dev->vlan_features = dev->features;
>>  
>>  	/* MTU range: 68 - 65535 */
>> @@ -2962,7 +2973,8 @@ static struct virtio_device_id id_table[] = {
>>  	VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ, \
>>  	VIRTIO_NET_F_CTRL_MAC_ADDR, \
>>  	VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS, \
>> -	VIRTIO_NET_F_SPEED_DUPLEX
>> +	VIRTIO_NET_F_SPEED_DUPLEX, \
>> +	VIRTIO_NET_F_HOST_SCTP_CSUM, VIRTIO_NET_F_GUEST_SCTP_CSUM
>>  
>>  static unsigned int features[] = {
>>  	VIRTNET_FEATURES,
>> diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
>> index f144216..28fffdc 100644
>> --- a/include/linux/virtio_net.h
>> +++ b/include/linux/virtio_net.h
>> @@ -39,6 +39,9 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
>>  
>>  		if (!skb_partial_csum_set(skb, start, off))
>>  			return -EINVAL;
>> +
>> +		if (hdr->flags & VIRTIO_NET_HDR_F_CSUM_NOT_INET)
>> +			skb->csum_not_inet = 1;
>>  	}
>>  
>>  	if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
>> @@ -91,6 +94,9 @@ static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
>>  				skb_checksum_start_offset(skb));
>>  		hdr->csum_offset = __cpu_to_virtio16(little_endian,
>>  				skb->csum_offset);
>> +
>> +		if (skb->csum_not_inet)
>> +			hdr->flags |= VIRTIO_NET_HDR_F_CSUM_NOT_INET;
>>  	} else if (has_data_valid &&
>>  		   skb->ip_summed == CHECKSUM_UNNECESSARY) {
>>  		hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
>> diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
>> index 5de6ed3..9dfca1a 100644
>> --- a/include/uapi/linux/virtio_net.h
>> +++ b/include/uapi/linux/virtio_net.h
>> @@ -57,6 +57,10 @@
>>  					 * Steering */
>>  #define VIRTIO_NET_F_CTRL_MAC_ADDR 23	/* Set MAC address */
>>  
>> +#define VIRTIO_NET_F_GUEST_SCTP_CSUM  61 /* Guest handles SCTP pks w/ partial
>> +					  * csum */
>> +#define VIRTIO_NET_F_HOST_SCTP_CSUM   62 /* HOST handles SCTP pkts w/ partial
>> +					  * csum */
>>  #define VIRTIO_NET_F_SPEED_DUPLEX 63	/* Device set linkspeed and duplex */
>>  
>>  #ifndef VIRTIO_NET_NO_LEGACY
>> @@ -101,6 +105,7 @@ struct virtio_net_config {
>>  struct virtio_net_hdr_v1 {
>>  #define VIRTIO_NET_HDR_F_NEEDS_CSUM	1	/* Use csum_start, csum_offset */
>>  #define VIRTIO_NET_HDR_F_DATA_VALID	2	/* Csum is valid */
>> +#define VIRTIO_NET_HDR_F_CSUM_NOT_INET  4       /* Checksum is not inet */
> 
> Both comment and name are not very informative.
> How about just saying CRC32c ?

It mirrors what's in the kernel, and I think the goal there was to make
it a bit more generic.  However, we can probably be specific here and add
another flag in the future if a different type of checksum would ever be used.

-vlad

> 
>>  	__u8 flags;
>>  #define VIRTIO_NET_HDR_GSO_NONE		0	/* Not a GSO frame */
>>  #define VIRTIO_NET_HDR_GSO_TCPV4	1	/* GSO frame, IPv4 TCP (TSO) */
>> -- 
>> 2.9.5
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: [PATCH V2 net-next 5/6] macvlan/macvtap: Add support for SCTP checksum offload.

[Vlad Yasevich]

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 the host or host hardware.
>>
>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
>> ---
>>  drivers/net/macvlan.c | 5 +++--
>>  drivers/net/tap.c     | 8 +++++---
>>  2 files changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>> index 725f4b4..646b730 100644
>> --- a/drivers/net/macvlan.c
>> +++ b/drivers/net/macvlan.c
>> @@ -834,7 +834,7 @@ static struct lock_class_key macvlan_netdev_addr_lock_key;
>>  
>>  #define ALWAYS_ON_OFFLOADS \
>>  	(NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_GSO_SOFTWARE | \
>> -	 NETIF_F_GSO_ROBUST | NETIF_F_GSO_ENCAP_ALL)
>> +	 NETIF_F_GSO_ROBUST | NETIF_F_GSO_ENCAP_ALL | NETIF_F_SCTP_CRC)
>>  
>>  #define ALWAYS_ON_FEATURES (ALWAYS_ON_OFFLOADS | NETIF_F_LLTX)
>>  
>> @@ -842,7 +842,8 @@ static struct lock_class_key macvlan_netdev_addr_lock_key;
>>  	(NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST | \
>>  	 NETIF_F_GSO | NETIF_F_TSO | NETIF_F_LRO | \
>>  	 NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_GRO | NETIF_F_RXCSUM | \
>> -	 NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER)
>> +	 NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER | \
>> +	 NETIF_F_SCTP_CRC)
>>  
>>  #define MACVLAN_STATE_MASK \
>>  	((1<<__LINK_STATE_NOCARRIER) | (1<<__LINK_STATE_DORMANT))
>> diff --git a/drivers/net/tap.c b/drivers/net/tap.c
>> index 9b6cb78..2c8512b 100644
>> --- a/drivers/net/tap.c
>> +++ b/drivers/net/tap.c
>> @@ -369,8 +369,7 @@ rx_handler_result_t tap_handle_frame(struct sk_buff **pskb)
>>  		 *	  check, we either support them all or none.
>>  		 */
>>  		if (skb->ip_summed == CHECKSUM_PARTIAL &&
>> -		    !(features & NETIF_F_CSUM_MASK) &&
>> -		    skb_checksum_help(skb))
>> +		    skb_csum_hwoffload_help(skb, features))
>>  			goto drop;
>>  		if (ptr_ring_produce(&q->ring, skb))
>>  			goto drop;
>> @@ -945,6 +944,9 @@ static int set_offload(struct tap_queue *q, unsigned long arg)
>>  		}
>>  	}
>>  
>> +	if (arg & TUN_F_SCTP_CSUM)
>> +		feature_mask |= NETIF_F_SCTP_CRC;
>> +
> 
> so this still affects TX, shouldn't this affect RX instead?

There is no bit to set on the RX path just like there is no bit to set on the RX patch
for TUN_F_CSUM.

We only invert TSO offloads, not checksum offloads as the comment below states.
For checksum,  macvtap has to compute the checksum itself in tap_handle_frame() above.
It uses tx feature bits to see if needs do to the checksum.

If you think we need another flag to macvtap to control RXCSUM, that would need to be
separate and cover standard TCP checksum as well.

-vlad

> 
> 
>>  	/* tun/tap driver inverts the usage for TSO offloads, where
>>  	 * setting the TSO bit means that the userspace wants to
>>  	 * accept TSO frames and turning it off means that user space
>> @@ -1077,7 +1079,7 @@ static long tap_ioctl(struct file *file, unsigned int cmd,
>>  	case TUNSETOFFLOAD:
>>  		/* let the user check for future flags */
>>  		if (arg & ~(TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 |
>> -			    TUN_F_TSO_ECN | TUN_F_UFO))
>> +			    TUN_F_TSO_ECN | TUN_F_UFO | TUN_F_SCTP_CSUM))
>>  			return -EINVAL;
>>  
>>  		rtnl_lock();
>> -- 
>> 2.9.5


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: [PATCH V2 net-next 5/6] macvlan/macvtap: Add support for SCTP checksum offload.

[Michael S. Tsirkin]

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 the host or host hardware.
> >>
> >> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> >> ---
> >>  drivers/net/macvlan.c | 5 +++--
> >>  drivers/net/tap.c     | 8 +++++---
> >>  2 files changed, 8 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> >> index 725f4b4..646b730 100644
> >> --- a/drivers/net/macvlan.c
> >> +++ b/drivers/net/macvlan.c
> >> @@ -834,7 +834,7 @@ static struct lock_class_key macvlan_netdev_addr_lock_key;
> >>  
> >>  #define ALWAYS_ON_OFFLOADS \
> >>  	(NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_GSO_SOFTWARE | \
> >> -	 NETIF_F_GSO_ROBUST | NETIF_F_GSO_ENCAP_ALL)
> >> +	 NETIF_F_GSO_ROBUST | NETIF_F_GSO_ENCAP_ALL | NETIF_F_SCTP_CRC)
> >>  
> >>  #define ALWAYS_ON_FEATURES (ALWAYS_ON_OFFLOADS | NETIF_F_LLTX)
> >>  
> >> @@ -842,7 +842,8 @@ static struct lock_class_key macvlan_netdev_addr_lock_key;
> >>  	(NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST | \
> >>  	 NETIF_F_GSO | NETIF_F_TSO | NETIF_F_LRO | \
> >>  	 NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_GRO | NETIF_F_RXCSUM | \
> >> -	 NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER)
> >> +	 NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER | \
> >> +	 NETIF_F_SCTP_CRC)
> >>  
> >>  #define MACVLAN_STATE_MASK \
> >>  	((1<<__LINK_STATE_NOCARRIER) | (1<<__LINK_STATE_DORMANT))
> >> diff --git a/drivers/net/tap.c b/drivers/net/tap.c
> >> index 9b6cb78..2c8512b 100644
> >> --- a/drivers/net/tap.c
> >> +++ b/drivers/net/tap.c
> >> @@ -369,8 +369,7 @@ rx_handler_result_t tap_handle_frame(struct sk_buff **pskb)
> >>  		 *	  check, we either support them all or none.
> >>  		 */
> >>  		if (skb->ip_summed == CHECKSUM_PARTIAL &&
> >> -		    !(features & NETIF_F_CSUM_MASK) &&
> >> -		    skb_checksum_help(skb))
> >> +		    skb_csum_hwoffload_help(skb, features))
> >>  			goto drop;
> >>  		if (ptr_ring_produce(&q->ring, skb))
> >>  			goto drop;
> >> @@ -945,6 +944,9 @@ static int set_offload(struct tap_queue *q, unsigned long arg)
> >>  		}
> >>  	}
> >>  
> >> +	if (arg & TUN_F_SCTP_CSUM)
> >> +		feature_mask |= NETIF_F_SCTP_CRC;
> >> +
> > 
> > so this still affects TX, shouldn't this affect RX instead?
> 
> There is no bit to set on the RX path just like there is no bit to set on the RX patch
> for TUN_F_CSUM.
> 
> We only invert TSO offloads, not checksum offloads as the comment below states.
> For checksum,  macvtap has to compute the checksum itself in tap_handle_frame() above.
> It uses tx feature bits to see if needs do to the checksum.
> 
> If you think we need another flag to macvtap to control RXCSUM, that would need to be
> separate and cover standard TCP checksum as well.
> 
> -vlad

Confused. What is the meaning of TUN_F_SCTP_CSUM? I assume this is
a way for userspace to tell tun device: "I can handle
packets without SCTP checksum, pls send them my way".

Now what is the implication for macvtap? And why  are
you setting NETIF_F_SCTP_CRC which is a flag
that affects packets sent by guest to host?


> > 
> > 
> >>  	/* tun/tap driver inverts the usage for TSO offloads, where
> >>  	 * setting the TSO bit means that the userspace wants to
> >>  	 * accept TSO frames and turning it off means that user space
> >> @@ -1077,7 +1079,7 @@ static long tap_ioctl(struct file *file, unsigned int cmd,
> >>  	case TUNSETOFFLOAD:
> >>  		/* let the user check for future flags */
> >>  		if (arg & ~(TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 |
> >> -			    TUN_F_TSO_ECN | TUN_F_UFO))
> >> +			    TUN_F_TSO_ECN | TUN_F_UFO | TUN_F_SCTP_CSUM))
> >>  			return -EINVAL;
> >>  
> >>  		rtnl_lock();
> >> -- 
> >> 2.9.5

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: [PATCH V2 net-next 5/6] macvlan/macvtap: Add support for SCTP checksum offload.

[Vlad Yasevich]

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 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@redhat.com>
>>>> ---
>>>>  drivers/net/macvlan.c | 5 +++--
>>>>  drivers/net/tap.c     | 8 +++++---
>>>>  2 files changed, 8 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>>>> index 725f4b4..646b730 100644
>>>> --- a/drivers/net/macvlan.c
>>>> +++ b/drivers/net/macvlan.c
>>>> @@ -834,7 +834,7 @@ static struct lock_class_key macvlan_netdev_addr_lock_key;
>>>>  
>>>>  #define ALWAYS_ON_OFFLOADS \
>>>>  	(NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_GSO_SOFTWARE | \
>>>> -	 NETIF_F_GSO_ROBUST | NETIF_F_GSO_ENCAP_ALL)
>>>> +	 NETIF_F_GSO_ROBUST | NETIF_F_GSO_ENCAP_ALL | NETIF_F_SCTP_CRC)
>>>>  
>>>>  #define ALWAYS_ON_FEATURES (ALWAYS_ON_OFFLOADS | NETIF_F_LLTX)
>>>>  
>>>> @@ -842,7 +842,8 @@ static struct lock_class_key macvlan_netdev_addr_lock_key;
>>>>  	(NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST | \
>>>>  	 NETIF_F_GSO | NETIF_F_TSO | NETIF_F_LRO | \
>>>>  	 NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_GRO | NETIF_F_RXCSUM | \
>>>> -	 NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER)
>>>> +	 NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER | \
>>>> +	 NETIF_F_SCTP_CRC)
>>>>  
>>>>  #define MACVLAN_STATE_MASK \
>>>>  	((1<<__LINK_STATE_NOCARRIER) | (1<<__LINK_STATE_DORMANT))
>>>> diff --git a/drivers/net/tap.c b/drivers/net/tap.c
>>>> index 9b6cb78..2c8512b 100644
>>>> --- a/drivers/net/tap.c
>>>> +++ b/drivers/net/tap.c
>>>> @@ -369,8 +369,7 @@ rx_handler_result_t tap_handle_frame(struct sk_buff **pskb)
>>>>  		 *	  check, we either support them all or none.
>>>>  		 */
>>>>  		if (skb->ip_summed == CHECKSUM_PARTIAL &&
>>>> -		    !(features & NETIF_F_CSUM_MASK) &&
>>>> -		    skb_checksum_help(skb))
>>>> +		    skb_csum_hwoffload_help(skb, features))
>>>>  			goto drop;
>>>>  		if (ptr_ring_produce(&q->ring, skb))
>>>>  			goto drop;
>>>> @@ -945,6 +944,9 @@ static int set_offload(struct tap_queue *q, unsigned long arg)
>>>>  		}
>>>>  	}
>>>>  
>>>> +	if (arg & TUN_F_SCTP_CSUM)
>>>> +		feature_mask |= NETIF_F_SCTP_CRC;
>>>> +
>>>
>>> so this still affects TX, shouldn't this affect RX instead?
>>
>> There is no bit to set on the RX path just like there is no bit to set on the RX patch
>> for TUN_F_CSUM.
>>
>> We only invert TSO offloads, not checksum offloads as the comment below states.
>> For checksum,  macvtap has to compute the checksum itself in tap_handle_frame() above.
>> It uses tx feature bits to see if needs do to the checksum.
>>
>> If you think we need another flag to macvtap to control RXCSUM, that would need to be
>> separate and cover standard TCP checksum as well.
>>
>> -vlad
> 
> Confused. What is the meaning of TUN_F_SCTP_CSUM? I assume this is
> a way for userspace to tell tun device: "I can handle
> packets without SCTP checksum, pls send them my way".

Yes,  just as TUN_F_CSUM means that tun device can handle packets with
partial tcp/udp checksum.

> 
> Now what is the implication for macvtap? 

The implication is exactly the same as for TUN_F_CSUM.  If the
flag is set on the macvtap device, the TX checksum feature is
turned on.

> And why  are
> you setting NETIF_F_SCTP_CRC which is a flag
> that affects packets sent by guest to host?

Mainly its because we are using just 1 flag to control checksum
offloading and we need to be able control both tx and rx paths.

What you are suggesting that we either invert what TUN_F_CSUM
is doing in macvtap case, or have another flag that lets us control
TX and RX paths separately.

Either case, that would be separate work.
-vlad

> 
> 
>>>
>>>
>>>>  	/* tun/tap driver inverts the usage for TSO offloads, where
>>>>  	 * setting the TSO bit means that the userspace wants to
>>>>  	 * accept TSO frames and turning it off means that user space
>>>> @@ -1077,7 +1079,7 @@ static long tap_ioctl(struct file *file, unsigned int cmd,
>>>>  	case TUNSETOFFLOAD:
>>>>  		/* let the user check for future flags */
>>>>  		if (arg & ~(TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 |
>>>> -			    TUN_F_TSO_ECN | TUN_F_UFO))
>>>> +			    TUN_F_TSO_ECN | TUN_F_UFO | TUN_F_SCTP_CSUM))
>>>>  			return -EINVAL;
>>>>  
>>>>  		rtnl_lock();
>>>> -- 
>>>> 2.9.5


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: [PATCH V2 net-next 5/6] macvlan/macvtap: Add support for SCTP checksum offload.

[Michael S. Tsirkin]

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 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@redhat.com>
> >>>> ---
> >>>>  drivers/net/macvlan.c | 5 +++--
> >>>>  drivers/net/tap.c     | 8 +++++---
> >>>>  2 files changed, 8 insertions(+), 5 deletions(-)
> >>>>
> >>>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> >>>> index 725f4b4..646b730 100644
> >>>> --- a/drivers/net/macvlan.c
> >>>> +++ b/drivers/net/macvlan.c
> >>>> @@ -834,7 +834,7 @@ static struct lock_class_key macvlan_netdev_addr_lock_key;
> >>>>  
> >>>>  #define ALWAYS_ON_OFFLOADS \
> >>>>  	(NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_GSO_SOFTWARE | \
> >>>> -	 NETIF_F_GSO_ROBUST | NETIF_F_GSO_ENCAP_ALL)
> >>>> +	 NETIF_F_GSO_ROBUST | NETIF_F_GSO_ENCAP_ALL | NETIF_F_SCTP_CRC)
> >>>>  
> >>>>  #define ALWAYS_ON_FEATURES (ALWAYS_ON_OFFLOADS | NETIF_F_LLTX)
> >>>>  
> >>>> @@ -842,7 +842,8 @@ static struct lock_class_key macvlan_netdev_addr_lock_key;
> >>>>  	(NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST | \
> >>>>  	 NETIF_F_GSO | NETIF_F_TSO | NETIF_F_LRO | \
> >>>>  	 NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_GRO | NETIF_F_RXCSUM | \
> >>>> -	 NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER)
> >>>> +	 NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER | \
> >>>> +	 NETIF_F_SCTP_CRC)
> >>>>  
> >>>>  #define MACVLAN_STATE_MASK \
> >>>>  	((1<<__LINK_STATE_NOCARRIER) | (1<<__LINK_STATE_DORMANT))
> >>>> diff --git a/drivers/net/tap.c b/drivers/net/tap.c
> >>>> index 9b6cb78..2c8512b 100644
> >>>> --- a/drivers/net/tap.c
> >>>> +++ b/drivers/net/tap.c
> >>>> @@ -369,8 +369,7 @@ rx_handler_result_t tap_handle_frame(struct sk_buff **pskb)
> >>>>  		 *	  check, we either support them all or none.
> >>>>  		 */
> >>>>  		if (skb->ip_summed == CHECKSUM_PARTIAL &&
> >>>> -		    !(features & NETIF_F_CSUM_MASK) &&
> >>>> -		    skb_checksum_help(skb))
> >>>> +		    skb_csum_hwoffload_help(skb, features))
> >>>>  			goto drop;
> >>>>  		if (ptr_ring_produce(&q->ring, skb))
> >>>>  			goto drop;
> >>>> @@ -945,6 +944,9 @@ static int set_offload(struct tap_queue *q, unsigned long arg)
> >>>>  		}
> >>>>  	}
> >>>>  
> >>>> +	if (arg & TUN_F_SCTP_CSUM)
> >>>> +		feature_mask |= NETIF_F_SCTP_CRC;
> >>>> +
> >>>
> >>> so this still affects TX, shouldn't this affect RX instead?
> >>
> >> There is no bit to set on the RX path just like there is no bit to set on the RX patch
> >> for TUN_F_CSUM.
> >>
> >> We only invert TSO offloads, not checksum offloads as the comment below states.
> >> For checksum,  macvtap has to compute the checksum itself in tap_handle_frame() above.
> >> It uses tx feature bits to see if needs do to the checksum.
> >>
> >> If you think we need another flag to macvtap to control RXCSUM, that would need to be
> >> separate and cover standard TCP checksum as well.
> >>
> >> -vlad
> > 
> > Confused. What is the meaning of TUN_F_SCTP_CSUM? I assume this is
> > a way for userspace to tell tun device: "I can handle
> > packets without SCTP checksum, pls send them my way".
> 
> Yes,  just as TUN_F_CSUM means that tun device can handle packets with
> partial tcp/udp checksum.
> 
> > 
> > Now what is the implication for macvtap? 
> 
> The implication is exactly the same as for TUN_F_CSUM.  If the
> flag is set on the macvtap device, the TX checksum feature is
> turned on.

I guess I will have to go back and re-read that code - I do not remember
what does TUN_F_CSUM does by now.  Here is a quick question that might
help me:

Let's assume userspace does not set TUN_F_SCTP_CSUM and device
does not calculate the checksums either. I would expect that with
macvtap this then behaves exactly like now with no overhead.

> 
> > And why  are
> > you setting NETIF_F_SCTP_CRC which is a flag
> > that affects packets sent by guest to host?
> 
> Mainly its because we are using just 1 flag to control checksum
> offloading and we need to be able control both tx and rx paths.

Well that's not really the case I think. What we have is controls for tx
offloads for tun. That's TUN_F_CSUM.
there are no rx offloads - userspace can send what it wants.

These are supposed to translate to rx offloads for macvtap.
tx offloads shouldn't be affected at all.

Maybe that's not the case - as I said need to go back and check.
Will try to find the time in the next couple of days.

> What you are suggesting that we either invert what TUN_F_CSUM
> is doing in macvtap case, or have another flag that lets us control
> TX and RX paths separately.
> 
> Either case, that would be separate work.
> -vlad

So assuming TUN_F_CSUM affects tx for macvtap do you
agree it's a bug? And should we add to it with
TUN_F_SCTP_CSUM doing the same?

> > 
> > 
> >>>
> >>>
> >>>>  	/* tun/tap driver inverts the usage for TSO offloads, where
> >>>>  	 * setting the TSO bit means that the userspace wants to
> >>>>  	 * accept TSO frames and turning it off means that user space
> >>>> @@ -1077,7 +1079,7 @@ static long tap_ioctl(struct file *file, unsigned int cmd,
> >>>>  	case TUNSETOFFLOAD:
> >>>>  		/* let the user check for future flags */
> >>>>  		if (arg & ~(TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 |
> >>>> -			    TUN_F_TSO_ECN | TUN_F_UFO))
> >>>> +			    TUN_F_TSO_ECN | TUN_F_UFO | TUN_F_SCTP_CSUM))
> >>>>  			return -EINVAL;
> >>>>  
> >>>>  		rtnl_lock();
> >>>> -- 
> >>>> 2.9.5

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: [PATCH V2 net-next 1/6] virtio: Add support for SCTP checksum offloading

[Michael S. Tsirkin]

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
> > > 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 addition virtio_net header flag which
> > > mirrors the skb->csum_not_inet flag.  This flags is used to indicate
> > > that is this an SCTP packet that needs its checksum computed by the
> > > lower layer.  In this case, the lower layer is the host hypervisor or
> > > possibly HW nic that supporst CRC32c offload.
> > >
> > > In the case that GUEST feature bit is flag, it will be possible to
> > > receive a virtio_net header with this bit set, which will set the
> > > corresponding skb bit.  SCTP protocol will be updated to correctly
> > > deal with it.
> > >
> > > Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> > > ---
> > >  drivers/net/virtio_net.c        | 14 +++++++++++++-
> > >  include/linux/virtio_net.h      |  6 ++++++
> > >  include/uapi/linux/virtio_net.h |  5 +++++
> > >  3 files changed, 24 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > index 7b187ec..34af280 100644
> > > --- a/drivers/net/virtio_net.c
> > > +++ b/drivers/net/virtio_net.c
> > > @@ -2148,6 +2148,8 @@ static int virtnet_clear_guest_offloads(struct virtnet_info *vi)
> > >
> > >  	if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_CSUM))
> > >  		offloads = 1ULL << VIRTIO_NET_F_GUEST_CSUM;
> > > +	if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_SCTP_CSUM))
> > > +		offloads |= 1ULL << VIRTIO_NET_F_GUEST_SCTP_CSUM;
> > >
> > >  	return virtnet_set_guest_offloads(vi, offloads);
> > >  }
> > > @@ -2160,6 +2162,8 @@ static int virtnet_restore_guest_offloads(struct virtnet_info *vi)
> > >  		return 0;
> > >  	if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_CSUM))
> > >  		offloads |= 1ULL << VIRTIO_NET_F_GUEST_CSUM;
> > > +	if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_SCTP_CSUM))
> > > +		offloads |= 1ULL << VIRTIO_NET_F_GUEST_SCTP_CSUM;
> > >
> > >  	return virtnet_set_guest_offloads(vi, offloads);
> > >  }
> > > @@ -2724,6 +2728,7 @@ static int virtnet_probe(struct virtio_device *vdev)
> > >  	/* Do we support "hardware" checksums? */
> > >  	if (virtio_has_feature(vdev, VIRTIO_NET_F_CSUM)) {
> > >  		/* This opens up the world of extra features. */
> > > +
> > >  		dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_SG;
> > >  		if (csum)
> > >  			dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG;
> > > @@ -2746,9 +2751,15 @@ static int virtnet_probe(struct virtio_device *vdev)
> > >  			dev->features |= dev->hw_features & NETIF_F_ALL_TSO;
> > >  		/* (!csum && gso) case will be fixed by register_netdev() */
> > >  	}
> > > +
> > >  	if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_CSUM))
> > >  		dev->features |= NETIF_F_RXCSUM;
> > >
> > > +	if (virtio_has_feature(vdev, VIRTIO_NET_F_HOST_SCTP_CSUM)) {
> > > +		dev->hw_features |= NETIF_F_SCTP_CRC;
> > > +		dev->features |= NETIF_F_SCTP_CRC;
> > > +	}
> > > +
> > >  	dev->vlan_features = dev->features;
> > >
> > >  	/* MTU range: 68 - 65535 */
> > > @@ -2962,7 +2973,8 @@ static struct virtio_device_id id_table[] = {
> > >  	VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ, \
> > >  	VIRTIO_NET_F_CTRL_MAC_ADDR, \
> > >  	VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS, \
> > > -	VIRTIO_NET_F_SPEED_DUPLEX
> > > +	VIRTIO_NET_F_SPEED_DUPLEX, \
> > > +	VIRTIO_NET_F_HOST_SCTP_CSUM, VIRTIO_NET_F_GUEST_SCTP_CSUM
> > >
> > >  static unsigned int features[] = {
> > >  	VIRTNET_FEATURES,
> > > diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> > > index f144216..28fffdc 100644
> > > --- a/include/linux/virtio_net.h
> > > +++ b/include/linux/virtio_net.h
> > > @@ -39,6 +39,9 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
> > >
> > >  		if (!skb_partial_csum_set(skb, start, off))
> > >  			return -EINVAL;
> > > +
> > > +		if (hdr->flags & VIRTIO_NET_HDR_F_CSUM_NOT_INET)
> > > +			skb->csum_not_inet = 1;
> > >  	}
> > >
> > >  	if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
> > > @@ -91,6 +94,9 @@ static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
> > >  				skb_checksum_start_offset(skb));
> > >  		hdr->csum_offset = __cpu_to_virtio16(little_endian,
> > >  				skb->csum_offset);
> > > +
> > > +		if (skb->csum_not_inet)
> > > +			hdr->flags |= VIRTIO_NET_HDR_F_CSUM_NOT_INET;
> > >  	} else if (has_data_valid &&
> > >  		   skb->ip_summed == CHECKSUM_UNNECESSARY) {
> > >  		hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
> > > diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
> > > index 5de6ed3..9dfca1a 100644
> > > --- a/include/uapi/linux/virtio_net.h
> > > +++ b/include/uapi/linux/virtio_net.h
> > > @@ -57,6 +57,10 @@
> > >  					 * Steering */
> > >  #define VIRTIO_NET_F_CTRL_MAC_ADDR 23	/* Set MAC address */
> > >
> > > +#define VIRTIO_NET_F_GUEST_SCTP_CSUM  61 /* Guest handles SCTP pks w/ partial
> > > +					  * csum */
> > > +#define VIRTIO_NET_F_HOST_SCTP_CSUM   62 /* HOST handles SCTP pkts w/ partial
> > > +					  * csum */
> > >  #define VIRTIO_NET_F_SPEED_DUPLEX 63	/* Device set linkspeed and duplex */
> > >
> > >  #ifndef VIRTIO_NET_NO_LEGACY
> > > @@ -101,6 +105,7 @@ struct virtio_net_config {
> > >  struct virtio_net_hdr_v1 {
> > >  #define VIRTIO_NET_HDR_F_NEEDS_CSUM	1	/* Use csum_start, csum_offset */
> > >  #define VIRTIO_NET_HDR_F_DATA_VALID	2	/* Csum is valid */
> > > +#define VIRTIO_NET_HDR_F_CSUM_NOT_INET  4       /* Checksum is not inet */
> >
> > Both comment and name are not very informative.
> > How about just saying CRC32c ?
> 
> csum_not_inet is following the nomenclature used in sk_buff. Initially
> Davide had named the sk_buff field after crc32c but then it was argued
> that maybe another check method may be introduced later and the name
> would be bogus, thus why the "csum_not_inet".

That's sk_buff internals, since Linux can change these
at any time without breaking anything.

virtio defines an ABI so we won't be able to make it
mean something else, need to document it fully.
"Go read linux net core code" is not a good answer
to the natural question "what does this bit in the
interface do".

> >
> > >  	__u8 flags;
> > >  #define VIRTIO_NET_HDR_GSO_NONE		0	/* Not a GSO frame */
> > >  #define VIRTIO_NET_HDR_GSO_TCPV4	1	/* GSO frame, IPv4 TCP (TSO) */
> > > --
> > > 2.9.5
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: [PATCH V2 net-next 5/6] macvlan/macvtap: Add support for SCTP checksum offload.

[Vlad Yasevich]

On 05/02/2018 10:17 AM, Michael S. Tsirkin wrote:
> 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 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@redhat.com>
>>>>>> ---
>>>>>>  drivers/net/macvlan.c | 5 +++--
>>>>>>  drivers/net/tap.c     | 8 +++++---
>>>>>>  2 files changed, 8 insertions(+), 5 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>>>>>> index 725f4b4..646b730 100644
>>>>>> --- a/drivers/net/macvlan.c
>>>>>> +++ b/drivers/net/macvlan.c
>>>>>> @@ -834,7 +834,7 @@ static struct lock_class_key macvlan_netdev_addr_lock_key;
>>>>>>  
>>>>>>  #define ALWAYS_ON_OFFLOADS \
>>>>>>  	(NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_GSO_SOFTWARE | \
>>>>>> -	 NETIF_F_GSO_ROBUST | NETIF_F_GSO_ENCAP_ALL)
>>>>>> +	 NETIF_F_GSO_ROBUST | NETIF_F_GSO_ENCAP_ALL | NETIF_F_SCTP_CRC)
>>>>>>  
>>>>>>  #define ALWAYS_ON_FEATURES (ALWAYS_ON_OFFLOADS | NETIF_F_LLTX)
>>>>>>  
>>>>>> @@ -842,7 +842,8 @@ static struct lock_class_key macvlan_netdev_addr_lock_key;
>>>>>>  	(NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST | \
>>>>>>  	 NETIF_F_GSO | NETIF_F_TSO | NETIF_F_LRO | \
>>>>>>  	 NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_GRO | NETIF_F_RXCSUM | \
>>>>>> -	 NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER)
>>>>>> +	 NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER | \
>>>>>> +	 NETIF_F_SCTP_CRC)
>>>>>>  
>>>>>>  #define MACVLAN_STATE_MASK \
>>>>>>  	((1<<__LINK_STATE_NOCARRIER) | (1<<__LINK_STATE_DORMANT))
>>>>>> diff --git a/drivers/net/tap.c b/drivers/net/tap.c
>>>>>> index 9b6cb78..2c8512b 100644
>>>>>> --- a/drivers/net/tap.c
>>>>>> +++ b/drivers/net/tap.c
>>>>>> @@ -369,8 +369,7 @@ rx_handler_result_t tap_handle_frame(struct sk_buff **pskb)
>>>>>>  		 *	  check, we either support them all or none.
>>>>>>  		 */
>>>>>>  		if (skb->ip_summed == CHECKSUM_PARTIAL &&
>>>>>> -		    !(features & NETIF_F_CSUM_MASK) &&
>>>>>> -		    skb_checksum_help(skb))
>>>>>> +		    skb_csum_hwoffload_help(skb, features))
>>>>>>  			goto drop;
>>>>>>  		if (ptr_ring_produce(&q->ring, skb))
>>>>>>  			goto drop;
>>>>>> @@ -945,6 +944,9 @@ static int set_offload(struct tap_queue *q, unsigned long arg)
>>>>>>  		}
>>>>>>  	}
>>>>>>  
>>>>>> +	if (arg & TUN_F_SCTP_CSUM)
>>>>>> +		feature_mask |= NETIF_F_SCTP_CRC;
>>>>>> +
>>>>>
>>>>> so this still affects TX, shouldn't this affect RX instead?
>>>>
>>>> There is no bit to set on the RX path just like there is no bit to set on the RX patch
>>>> for TUN_F_CSUM.
>>>>
>>>> We only invert TSO offloads, not checksum offloads as the comment below states.
>>>> For checksum,  macvtap has to compute the checksum itself in tap_handle_frame() above.
>>>> It uses tx feature bits to see if needs do to the checksum.
>>>>
>>>> If you think we need another flag to macvtap to control RXCSUM, that would need to be
>>>> separate and cover standard TCP checksum as well.
>>>>
>>>> -vlad
>>>
>>> Confused. What is the meaning of TUN_F_SCTP_CSUM? I assume this is
>>> a way for userspace to tell tun device: "I can handle
>>> packets without SCTP checksum, pls send them my way".
>>
>> Yes,  just as TUN_F_CSUM means that tun device can handle packets with
>> partial tcp/udp checksum.
>>
>>>
>>> Now what is the implication for macvtap? 
>>
>> The implication is exactly the same as for TUN_F_CSUM.  If the
>> flag is set on the macvtap device, the TX checksum feature is
>> turned on.
> 
> I guess I will have to go back and re-read that code - I do not remember
> what does TUN_F_CSUM does by now.  Here is a quick question that might
> help me:
> 
> Let's assume userspace does not set TUN_F_SCTP_CSUM and device
> does not calculate the checksums either. I would expect that with
> macvtap this then behaves exactly like now with no overhead.

correct.

> 
>>
>>> And why  are
>>> you setting NETIF_F_SCTP_CRC which is a flag
>>> that affects packets sent by guest to host?
>>
>> Mainly its because we are using just 1 flag to control checksum
>> offloading and we need to be able control both tx and rx paths.
> 
> Well that's not really the case I think. What we have is controls for tx
> offloads for tun. That's TUN_F_CSUM.
> there are no rx offloads - userspace can send what it wants.
> 
> These are supposed to translate to rx offloads for macvtap.
> tx offloads shouldn't be affected at all.

Ok.  This is how it works for TSO, but looks like there was a disconnect
on the checksum.   In both tun and macvtap case, TUN_F_CSUM controls
the tx checksum feature bit.

> 
> Maybe that's not the case - as I said need to go back and check.
> Will try to find the time in the next couple of days.
> 
>> What you are suggesting that we either invert what TUN_F_CSUM
>> is doing in macvtap case, or have another flag that lets us control
>> TX and RX paths separately.
>>
>> Either case, that would be separate work.
>> -vlad
> 
> So assuming TUN_F_CSUM affects tx for macvtap do you
> agree it's a bug? And should we add to it with
> TUN_F_SCTP_CSUM doing the same?

let me think about what it would look like if TUN_F_CSUM
controlled the rx bits...

-vlad

> 
>>>
>>>
>>>>>
>>>>>
>>>>>>  	/* tun/tap driver inverts the usage for TSO offloads, where
>>>>>>  	 * setting the TSO bit means that the userspace wants to
>>>>>>  	 * accept TSO frames and turning it off means that user space
>>>>>> @@ -1077,7 +1079,7 @@ static long tap_ioctl(struct file *file, unsigned int cmd,
>>>>>>  	case TUNSETOFFLOAD:
>>>>>>  		/* let the user check for future flags */
>>>>>>  		if (arg & ~(TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 |
>>>>>> -			    TUN_F_TSO_ECN | TUN_F_UFO))
>>>>>> +			    TUN_F_TSO_ECN | TUN_F_UFO | TUN_F_SCTP_CSUM))
>>>>>>  			return -EINVAL;
>>>>>>  
>>>>>>  		rtnl_lock();
>>>>>> -- 
>>>>>> 2.9.5


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: [PATCH V2 net-next 4/6] tun: Add support for SCTP checksum offload

[Vlad Yasevich]

On 05/02/2018 10:56 AM, Marcelo Ricardo Leitner wrote:
> On Wed, May 02, 2018 at 11:53:47AM -0300, Marcelo Ricardo Leitner wrote:
>> On Tue, May 01, 2018 at 10:07:37PM -0400, Vladislav Yasevich wrote:
>>> Adds a new tun offload flag to allow for SCTP checksum offload.
>>> The flag has to be set by the user and defaults to "no offload".
>>
>> I'm confused here:
>>
>>> +++ b/drivers/net/tun.c
>>> @@ -216,7 +216,7 @@ struct tun_struct {
>>>  	struct net_device	*dev;
>>>  	netdev_features_t	set_features;
>>>  #define TUN_USER_FEATURES (NETIF_F_HW_CSUM|NETIF_F_TSO_ECN|NETIF_F_TSO| \
>>> -			  NETIF_F_TSO6)
>>> +			  NETIF_F_TSO6|NETIF_F_SCTP_CRC)
>>
>> Doesn't adding it here mean it defaults to "offload", instead?
>>
>> later on, it does:
>>                 dev->hw_features = NETIF_F_SG | NETIF_F_FRAGLIST |
>>                                    TUN_USER_FEATURES | NETIF_F_HW_VLAN_CTAG_TX |
>>                                    NETIF_F_HW_VLAN_STAG_TX;
> 
> Missed to paste the next line too:
>                 dev->features = dev->hw_features | NETIF_F_LLTX;
> 

Yes, as a software device, we can default it to on.  However, qemu will 0-out
the features and then set them up based on the guest (just like regular checksum).

-vlad



---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org