[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120721220534.GA22912@redhat.com>
Date: Sun, 22 Jul 2012 01:05:34 +0300
From: "Michael S. Tsirkin" <mst@...hat.com>
To: David Miller <davem@...emloft.net>
Cc: jasowang@...hat.com, eric.dumazet@...il.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
ebiederm@...ssion.com, Ian Campbell <Ian.Campbell@...rix.com>
Subject: Re: [PATCHv3 0/6] tun zerocopy support
On Fri, Jul 20, 2012 at 05:49:02PM -0700, David Miller wrote:
> From: "Michael S. Tsirkin" <mst@...hat.com>
> Date: Fri, 20 Jul 2012 22:23:03 +0300
>
> > Same as with macvtap, I get single-percentage wins in CPU utilization
> > on guest to external from this patchset, and a performance regression on
> > guest to host, so more work is needed until this feature can move out of
> > experimental status, but I think it's useful for some people already.
> >
> > Pls review and consider for 3.6.
>
> It doesn't improve performance in one case, and hurts performance in
> another.
>
> You'll have to give me a more compelling argument than that. You've
> just given me every reason not to include these patches in 3.6
OK let me clarify a bit, I think this wasn't explained well:
it's not true that this makes users suffer :)
This patch has no effect unless experimental zero copy mode in vhost-net
is enabled, and it is very clearly marked as experimental.
I agree a small win in CPU use is nothing to write home about,
I don't yet understand why the win is so small - macvtap has zero copy
supported for a while and it has exactly same issues.
I hope adding tun zerocopy support upstream will help us
make progress faster and find the bottleneck, so far not many people use
macvtap so zero copy mode there didn't make progress.
I do know why local performance regresses with zero copy enabled:
instead of plain copy to user we got get user pages and then memcpy.
We'll need some logic here to detect this and turn off zero copy.
The core patches will also be helpful for Ian's more ambitious work.
Overall I think it's a step in the right direction and it's easier to
work if core parts are upstream, but if you think we need to wait
until the gains are more significant, I understand that too.
--
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists