DPDK patches and discussions
 help / color / mirror / Atom feed
From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: Jiayu Hu <jiayu.hu@intel.com>, dev@dpdk.org
Cc: yliu@fridaylinux.org, jianfeng.tan@intel.com
Subject: Re: [dpdk-dev] [PATCH] vhost: support UDP Fragmentation Offload
Date: Wed, 6 Dec 2017 09:36:57 +0100	[thread overview]
Message-ID: <b1525410-e84b-1bc0-9f4f-fd057e578be7@redhat.com> (raw)
In-Reply-To: <1511247412-130965-1-git-send-email-jiayu.hu@intel.com>



On 11/21/2017 07:56 AM, Jiayu Hu wrote:
> In virtio, UDP Fragmentation Offload (UFO) includes two parts: host UFO
> and guest UFO. Guest UFO means the frontend can receive large UDP packets,
> and host UFO means the backend can receive large UDP packets. This patch
> supports host UFO and guest UFO for vhost-user.
> 
> Signed-off-by: Jiayu Hu <jiayu.hu@intel.com>
> ---
>   lib/librte_mbuf/rte_mbuf.h    |  7 +++++++
>   lib/librte_vhost/vhost.h      |  2 ++
>   lib/librte_vhost/virtio_net.c | 10 ++++++++++
>   3 files changed, 19 insertions(+)
> 
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index ce8a05d..3d8cfc9 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -209,6 +209,13 @@ extern "C" {
>   /* add new TX flags here */
>   
>   /**
> + * UDP Fragmentation Offload flag. This flag is used for enabling UDP
> + * fragmentation in SW or in HW. When use UFO, mbuf->tso_segsz is used
> + * to store the MSS of UDP fragments.
> + */
> +#define PKT_TX_UDP_SEG	(1ULL << 42)
> +
> +/**
>    * Request security offload processing on the TX packet.
>    */
>   #define PKT_TX_SEC_OFFLOAD 		(1ULL << 43)
> diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
> index 1cc81c1..fc109ef 100644
> --- a/lib/librte_vhost/vhost.h
> +++ b/lib/librte_vhost/vhost.h
> @@ -206,10 +206,12 @@ struct vhost_msg {
>   				(1ULL << VHOST_USER_F_PROTOCOL_FEATURES) | \
>   				(1ULL << VIRTIO_NET_F_HOST_TSO4) | \
>   				(1ULL << VIRTIO_NET_F_HOST_TSO6) | \
> +				(1ULL << VIRTIO_NET_F_HOST_UFO) | \
>   				(1ULL << VIRTIO_NET_F_CSUM)    | \
>   				(1ULL << VIRTIO_NET_F_GUEST_CSUM) | \
>   				(1ULL << VIRTIO_NET_F_GUEST_TSO4) | \
>   				(1ULL << VIRTIO_NET_F_GUEST_TSO6) | \
> +				(1ULL << VIRTIO_NET_F_GUEST_UFO) | \

I actually have the same question as for GSO.
Dos it impact performance as it seems enabled by default in QEMU?
How do you test it?

Thanks,
Maxime

>   				(1ULL << VIRTIO_RING_F_INDIRECT_DESC) | \
>   				(1ULL << VIRTIO_NET_F_MTU) | \
>   				(1ULL << VIRTIO_F_IOMMU_PLATFORM))
> diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
> index 6fee16e..3a3a0ad 100644
> --- a/lib/librte_vhost/virtio_net.c
> +++ b/lib/librte_vhost/virtio_net.c
> @@ -188,6 +188,11 @@ virtio_enqueue_offload(struct rte_mbuf *m_buf, struct virtio_net_hdr *net_hdr)
>   		net_hdr->gso_size = m_buf->tso_segsz;
>   		net_hdr->hdr_len = m_buf->l2_len + m_buf->l3_len
>   					+ m_buf->l4_len;
> +	} else if (m_buf->ol_flags & PKT_TX_UDP_SEG) {
> +		net_hdr->gso_type = VIRTIO_NET_HDR_GSO_UDP;
> +		net_hdr->gso_size = m_buf->tso_segsz;
> +		net_hdr->hdr_len = m_buf->l2_len + m_buf->l3_len +
> +			m_buf->l4_len;
>   	} else {
>   		ASSIGN_UNLESS_EQUAL(net_hdr->gso_type, 0);
>   		ASSIGN_UNLESS_EQUAL(net_hdr->gso_size, 0);
> @@ -834,6 +839,11 @@ vhost_dequeue_offload(struct virtio_net_hdr *hdr, struct rte_mbuf *m)
>   			m->tso_segsz = hdr->gso_size;
>   			m->l4_len = (tcp_hdr->data_off & 0xf0) >> 2;
>   			break;
> +		case VIRTIO_NET_HDR_GSO_UDP:
> +			m->ol_flags |= PKT_TX_UDP_SEG;
> +			m->tso_segsz = hdr->gso_size;
> +			m->l4_len = sizeof(struct udp_hdr);
> +			break;
>   		default:
>   			RTE_LOG(WARNING, VHOST_DATA,
>   				"unsupported gso type %u.\n", hdr->gso_type);
> 

  parent reply	other threads:[~2017-12-06  8:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-21  6:56 Jiayu Hu
2017-11-21  7:12 ` Stephen Hemminger
2017-11-21  7:41   ` Hu, Jiayu
2017-11-21 14:33     ` Neil Horman
2017-12-05 14:57 ` Maxime Coquelin
2017-12-06  8:36 ` Maxime Coquelin [this message]
2017-12-07 13:14   ` Hu, Jiayu
2017-12-25  1:48 ` Yao, Lei A
2017-12-27 14:34 ` Yuanhan Liu
2018-01-08 14:27 ` Yuanhan Liu
2018-01-16 11:20   ` Thomas Monjalon
2018-01-16 12:21     ` Olivier Matz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b1525410-e84b-1bc0-9f4f-fd057e578be7@redhat.com \
    --to=maxime.coquelin@redhat.com \
    --cc=dev@dpdk.org \
    --cc=jianfeng.tan@intel.com \
    --cc=jiayu.hu@intel.com \
    --cc=yliu@fridaylinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).