All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: vyasevic@redhat.com
Cc: "David S. Miller" <davem@davemloft.net>,
	Jason Wang <jasowang@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	netdev@vger.kernel.org, KVM list <kvm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: macvtap performance regression (bisected) between 3.13 and 3.14-rc1
Date: Sat, 01 Mar 2014 12:15:14 +0100	[thread overview]
Message-ID: <5311C142.6040509@de.ibm.com> (raw)
In-Reply-To: <53110A62.7070109@redhat.com>

On 28/02/14 23:14, Vlad Yasevich wrote:
> On 02/27/2014 03:52 PM, Christian Borntraeger wrote:
>> Vlad,
>>
>> commit 6acf54f1cf0a6747bac9fea26f34cfc5a9029523
>>     macvtap: Add support of packet capture on macvtap device.
>>
>> causes a performance regression for iperf traffic between two KVM guests
>> on my s390 system. Both guests are connected via two macvtaps on the same OSA
>> network card.
>> Before that patch I get ~20 Gbit/sec between two guests, afterwards I get
>> ~4Gbit/sec
>>
>> Latency seems to be unchanges (uperf 1byte ping pong).
>>
>> According to ifconfig in the guest, I have ~ 1500 bytes per packet with this
>> patch and ~  40000 bytes without. So for some reason this patch causes the
>> network stack to do segmentation. (the guest kernel stays the same, only host 
>> kernel is changed).
>>
>> Any ideas?
> 
> I am looking.  It shouldn't cause addition segmentations and when I ran
> netperf on the code I didn't see any difference in the throughput.

Dont know if the different bytes/packets ratio is really the reason or
just a side effect. As a hint: the underlying network device does not support
segmentation, but this should not matter for traffic between to guests.

Maybe you remember, we had a similar situation with commit 3e4f8b787370978733ca6cae452720a4f0c296b8
(macvtap: Perform GSO on forwarding path), the setup is basically the same.


Christian

  reply	other threads:[~2014-03-01 11:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-27 20:52 macvtap performance regression (bisected) between 3.13 and 3.14-rc1 Christian Borntraeger
2014-02-28 22:14 ` Vlad Yasevich
2014-03-01 11:15   ` Christian Borntraeger [this message]
2014-03-01 19:27     ` Vlad Yasevich
2014-03-02  1:21       ` Vlad Yasevich
2014-03-03  9:13         ` Christian Borntraeger
2014-03-03 19:36           ` Vlad Yasevich
2014-03-03  9:11       ` Christian Borntraeger

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=5311C142.6040509@de.ibm.com \
    --to=borntraeger@de.ibm.com \
    --cc=davem@davemloft.net \
    --cc=jasowang@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=vyasevic@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.