From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Maxime Coquelin <maxime.coquelin@redhat.com>,
Stephen Hemminger <stephen@networkplumber.org>,
dev@dpdk.org, qemu-devel@nongnu.org
Subject: Re: [dpdk-dev] [Qemu-devel] [PATCH 1/2] vhost: enable any layout feature
Date: Mon, 10 Oct 2016 12:05:31 +0800 [thread overview]
Message-ID: <20161010040531.GZ1597@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <20160930221241-mutt-send-email-mst@kernel.org>
On Fri, Sep 30, 2016 at 10:16:43PM +0300, Michael S. Tsirkin wrote:
> > > And the same is done is done in DPDK:
> > >
> > > static inline int __attribute__((always_inline))
> > > copy_desc_to_mbuf(struct virtio_net *dev, struct vring_desc *descs,
> > > uint16_t max_desc, struct rte_mbuf *m, uint16_t desc_idx,
> > > struct rte_mempool *mbuf_pool)
> > > {
> > > ...
> > > /*
> > > * A virtio driver normally uses at least 2 desc buffers
> > > * for Tx: the first for storing the header, and others
> > > * for storing the data.
> > > */
> > > if (likely((desc->len == dev->vhost_hlen) &&
> > > (desc->flags & VRING_DESC_F_NEXT) != 0)) {
> > > desc = &descs[desc->next];
> > > if (unlikely(desc->flags & VRING_DESC_F_INDIRECT))
> > > return -1;
> > >
> > > desc_addr = gpa_to_vva(dev, desc->addr);
> > > if (unlikely(!desc_addr))
> > > return -1;
> > >
> > > rte_prefetch0((void *)(uintptr_t)desc_addr);
> > >
> > > desc_offset = 0;
> > > desc_avail = desc->len;
> > > nr_desc += 1;
> > >
> > > PRINT_PACKET(dev, (uintptr_t)desc_addr, desc->len, 0);
> > > } else {
> > > desc_avail = desc->len - dev->vhost_hlen;
> > > desc_offset = dev->vhost_hlen;
> > > }
> >
> > Actually, the header is parsed in DPDK vhost implementation.
> > But as Virtio PMD provides a zero'ed header, we could just parse
> > the header only if VIRTIO_NET_F_NO_TX_HEADER is not negotiated.
>
> host can always skip the header parse if it wants to.
> It didn't seem worth it to add branches there but
> if I'm wrong, by all means code it up.
It's added by following commit, which yields about 10% performance
boosts for PVP case (with 64B packet size).
At that time, a packet always use 2 descs. Since indirect desc is
enabled (by default) now, the assumption is not true then. What's
worse, it might even slow things a bit down. That should also be
part of the reason why performance is slightly worse than before.
--yliu
commit 1d41d77cf81c448c1b09e1e859bfd300e2054a98
Author: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Date: Mon May 2 17:46:17 2016 -0700
vhost: optimize dequeue for small packets
A virtio driver normally uses at least 2 desc buffers for Tx: the
first for storing the header, and the others for storing the data.
Therefore, we could fetch the first data desc buf before the main
loop, and do the copy first before the check of "are we done yet?".
This could save one check for small packets that just have one data
desc buffer and need one mbuf to store it.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Acked-by: Huawei Xie <huawei.xie@intel.com>
Tested-by: Rich Lane <rich.lane@bigswitch.com>
next prev parent reply other threads:[~2016-10-10 4:04 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-26 6:40 [dpdk-dev] [PATCH 0/2] enables vhost/virtio " Yuanhan Liu
2016-09-26 6:40 ` [dpdk-dev] [PATCH 1/2] vhost: enable " Yuanhan Liu
2016-09-26 18:01 ` Stephen Hemminger
2016-09-26 19:24 ` Michael S. Tsirkin
2016-09-27 3:11 ` Yuanhan Liu
2016-09-27 19:48 ` Stephen Hemminger
2016-09-27 19:56 ` Michael S. Tsirkin
2016-09-28 2:28 ` Yuanhan Liu
2016-09-29 15:30 ` [dpdk-dev] [Qemu-devel] " Maxime Coquelin
2016-09-29 17:57 ` Michael S. Tsirkin
2016-09-29 20:05 ` Maxime Coquelin
2016-09-29 20:21 ` Michael S. Tsirkin
2016-09-29 21:23 ` Maxime Coquelin
2016-09-30 12:05 ` Maxime Coquelin
2016-09-30 19:16 ` Michael S. Tsirkin
2016-10-10 4:05 ` Yuanhan Liu [this message]
2016-10-10 4:17 ` Michael S. Tsirkin
2016-10-10 4:22 ` Yuanhan Liu
2016-10-10 4:25 ` Michael S. Tsirkin
2016-10-10 12:40 ` Maxime Coquelin
2016-10-10 14:42 ` Yuanhan Liu
2016-10-10 14:54 ` Maxime Coquelin
2016-10-11 6:04 ` Yuanhan Liu
2016-10-11 6:39 ` Maxime Coquelin
2016-10-11 6:49 ` Yuanhan Liu
2016-10-03 14:20 ` Maxime Coquelin
2016-10-10 3:37 ` Yuanhan Liu
2016-10-10 3:46 ` Michael S. Tsirkin
2016-10-10 3:59 ` Yuanhan Liu
2016-10-10 4:16 ` Wang, Zhihong
2016-10-10 4:24 ` Michael S. Tsirkin
2016-10-10 4:39 ` Michael S. Tsirkin
2016-10-11 6:57 ` Yuanhan Liu
2016-10-12 3:21 ` Yuanhan Liu
[not found] ` <F5DF4F0E3AFEF648ADC1C3C33AD4DBF16C2409EB@SHSMSX101.ccr.corp.intel.com>
2016-10-13 2:52 ` Yang, Zhiyong
2016-10-10 3:50 ` Yuanhan Liu
2016-10-09 23:20 ` [dpdk-dev] " Michael S. Tsirkin
2016-10-10 3:03 ` Yuanhan Liu
2016-10-10 3:04 ` Michael S. Tsirkin
2016-10-10 3:10 ` Yuanhan Liu
2016-09-26 6:40 ` [dpdk-dev] [PATCH 2/2] net/virtio: " Yuanhan Liu
2016-09-26 18:04 ` Stephen Hemminger
2016-09-29 18:00 ` Michael S. Tsirkin
2016-09-29 18:01 ` Michael S. Tsirkin
2016-11-10 15:18 ` [dpdk-dev] [PATCH 0/2] enables vhost/virtio " Michael S. Tsirkin
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=20161010040531.GZ1597@yliu-dev.sh.intel.com \
--to=yuanhan.liu@linux.intel.com \
--cc=dev@dpdk.org \
--cc=maxime.coquelin@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stephen@networkplumber.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).