All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rick Jones <rick.jones2@hp.com>
To: Cong Wang <amwang@redhat.com>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>
Subject: Re: Regression: too many packets with incorrect checksum
Date: Thu, 09 May 2013 09:25:31 -0700	[thread overview]
Message-ID: <518BCDFB.4090004@hp.com> (raw)
In-Reply-To: <1368091063.12413.9.camel@cr0>

On 05/09/2013 02:17 AM, Cong Wang wrote:
> On Thu, 2013-05-09 at 16:36 +0800, Cong Wang wrote:
>>
>> Running another RHEL6 KVM guest, it doesn't have this problem, so it is
>> not related with KVM environment.
>
> I thought it might be due to tcpdump receives a packet which is
> checksummed partially while the wire receives a correct one, but netperf
> shows that is wrong, apparently it hurts performance:
>
> With latest -net:
>
> ~% netperf -4 -H 192.168.122.74
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> 192.168.122.74 () port 0 AF_INET
> Recv   Send    Send
> Socket Socket  Message  Elapsed
> Size   Size    Size     Time     Throughput
> bytes  bytes   bytes    secs.    10^6bits/sec
>
>   87380  16384  16384    10.20     105.19

That the test ran 200 milliseconds "long" (in a LAN environment and 
compared to the other kernel) is another clue that things were not 
entirely well.  I suspect that were you to have netperf emit 
local_transport_retrans:

netperf -4 -H 192.168.122.74 -- -o 
throughput,elapsed_time,local_transport_retrans

you would see a non-trivial number of retransmissions on the connection. 
  You've no doubt already seen that in netstat -s, but the 
per-connection stuff netperf can emit can be helpful when there are 
other things going-on on the system at the same time.

happy benchmarking,

rick ones

>
>
> With a RHEL6 kernel:
>
> ~% netperf -4 -H 192.168.122.101
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> 192.168.122.101 () port 0 AF_INET
> Recv   Send    Send
> Socket Socket  Message  Elapsed
> Size   Size    Size     Time     Throughput
> bytes  bytes   bytes    secs.    10^6bits/sec
>
>   87380  16384  16384    10.00    5528.64
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

      reply	other threads:[~2013-05-09 16:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-08 11:51 Regression: too many packets with incorrect checksum Cong Wang
2013-05-08 12:15 ` PJ Waskiewicz
2013-05-08 12:22   ` Cong Wang
2013-05-09  8:36 ` Cong Wang
2013-05-09  9:17   ` Cong Wang
2013-05-09 16:25     ` Rick Jones [this message]

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=518BCDFB.4090004@hp.com \
    --to=rick.jones2@hp.com \
    --cc=amwang@redhat.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.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 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.