From: "Hu, Jiayu" <jiayu.hu@intel.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "yliu@fridaylinux.org" <yliu@fridaylinux.org>,
"Tan, Jianfeng" <jianfeng.tan@intel.com>
Subject: Re: [dpdk-dev] [PATCH] vhost: support UDP Fragmentation Offload
Date: Thu, 7 Dec 2017 13:14:41 +0000 [thread overview]
Message-ID: <ED946F0BEFE0A141B63BABBD629A2A9B38816FD0@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <b1525410-e84b-1bc0-9f4f-fd057e578be7@redhat.com>
Hi Maxime,
> -----Original Message-----
> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
> Sent: Wednesday, December 6, 2017 4:37 PM
> To: Hu, Jiayu <jiayu.hu@intel.com>; dev@dpdk.org
> Cc: yliu@fridaylinux.org; Tan, Jianfeng <jianfeng.tan@intel.com>
> Subject: Re: [dpdk-dev] [PATCH] vhost: support UDP Fragmentation Offload
>
>
>
> 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?
When enable host/guest UFO, the frontend and the backend can communicate
via large UDP packets, thus reducing the number of packets to be processed.
It's similar with TSO for virtio. Therefore, I think host/guest UFO can bring
performance gains.
> How do you test it?
We launch testpmd with two vhost-user ports, which connect to two VMs in one
server. When launch qemu, we enable host and guest UFO with command "host_ufo=on,
guest_ufo=on,csum=on". Then we run iperf in the two VMs to send large UDP packets.
If you use "show port xstats all" in testpmd, you can see the vhost-user port can receive
large UDP packets, which means host_ufo works. Additionally, if the forwarded large UDP
packets can be received by the VM, it means guest_ufo also works.
Thanks,
Jiayu
>
> 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);
> >
next prev parent reply other threads:[~2017-12-07 13:14 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
2017-12-07 13:14 ` Hu, Jiayu [this message]
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=ED946F0BEFE0A141B63BABBD629A2A9B38816FD0@shsmsx102.ccr.corp.intel.com \
--to=jiayu.hu@intel.com \
--cc=dev@dpdk.org \
--cc=jianfeng.tan@intel.com \
--cc=maxime.coquelin@redhat.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).