netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sabrina Dubroca <sd@queasysnail.net>
To: Vladislav Yasevich <vyasevich@gmail.com>
Cc: netdev@vger.kernel.org, herbert@gondor.apana.org.au,
	hannes@stressinduktion.org,
	Vladislav Yasevich <vyasevic@redhat.com>
Subject: Re: [PATCH net-next 6/6] ipv6: Allow for partial checksums on non-ufo packets
Date: Tue, 10 Feb 2015 15:07:04 +0100	[thread overview]
Message-ID: <20150210140704.GA3372@kria> (raw)
In-Reply-To: <1422718818-21093-7-git-send-email-vyasevic@redhat.com>

2015-01-31, 10:40:18 -0500, Vladislav Yasevich wrote:
> Currntly, if we are not doing UFO on the packet, all UDP
> packets will start with CHECKSUM_NONE and thus perform full
> checksum computations in software even if device support
> IPv6 checksum offloading.
> 
> Let's start start with CHECKSUM_PARTIAL if the device
> supports it and we are sending only a single packet at
> or below mtu size.
> 
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> ---

This patch causes ICMPv6 checksumming issues for me.

On my tg3 device and on a qemu VM with e1000 emulation, outgoing pings
have a bad checksum.  Router solicitations also have a bad checksum,
so autoconf fails.  When I revert this patch, or when I disable
tx-checksumming with ethtool, everything looks okay again.

On tg3, replies to ping seem always good.

On e1000, replies to ping work (more or less).  Sometimes the checksum
is bad, sometimes it's good.


% ping6 fec0::3456
PING fec0::3456(fec0::3456) 56 data bytes
64 bytes from fec0::3456: icmp_seq=1 ttl=64 time=0.433 ms
64 bytes from fec0::3456: icmp_seq=2 ttl=64 time=0.457 ms
64 bytes from fec0::3456: icmp_seq=10 ttl=64 time=0.448 ms
64 bytes from fec0::3456: icmp_seq=11 ttl=64 time=0.451 ms
64 bytes from fec0::3456: icmp_seq=18 ttl=64 time=0.485 ms
64 bytes from fec0::3456: icmp_seq=20 ttl=64 time=0.476 ms
64 bytes from fec0::3456: icmp_seq=22 ttl=64 time=0.448 ms
64 bytes from fec0::3456: icmp_seq=26 ttl=64 time=0.438 ms
64 bytes from fec0::3456: icmp_seq=27 ttl=64 time=0.413 ms
64 bytes from fec0::3456: icmp_seq=28 ttl=64 time=0.452 ms
64 bytes from fec0::3456: icmp_seq=29 ttl=64 time=0.440 ms
64 bytes from fec0::3456: icmp_seq=30 ttl=64 time=0.485 ms
64 bytes from fec0::3456: icmp_seq=32 ttl=64 time=0.473 ms
64 bytes from fec0::3456: icmp_seq=33 ttl=64 time=0.472 ms
64 bytes from fec0::3456: icmp_seq=34 ttl=64 time=0.395 ms
64 bytes from fec0::3456: icmp_seq=35 ttl=64 time=0.456 ms
64 bytes from fec0::3456: icmp_seq=36 ttl=64 time=0.409 ms
^C
--- fec0::3456 ping statistics ---
36 packets transmitted, 17 received, 52% packet loss, time 34998ms
rtt min/avg/max/mdev = 0.395/0.448/0.485/0.037 ms


I've seen a few strange source addresses, but I don't know if it's
related.

% ping6 fec0::3456
PING fec0::3456(fec0::3456) 56 data bytes
64 bytes from fec0::ff:ff00:0:3456: icmp_seq=1 ttl=64 time=0.423 ms   <---
64 bytes from fec0::3456: icmp_seq=4 ttl=64 time=0.396 ms
64 bytes from fec0::3456: icmp_seq=5 ttl=64 time=0.400 ms


This could be a driver issue, or just exposing another problem
somewhere else, I don't know.

Any idea?


Thanks

-- 
Sabrina

  reply	other threads:[~2015-02-10 14:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-31 15:40 [PATCH net-next 0/6] ipv6: Add lockless UDP send path Vladislav Yasevich
2015-01-31 15:40 ` [PATCH net-next 1/6] ipv6: pull cork initialization into its own function Vladislav Yasevich
2015-01-31 15:40 ` [PATCH net-next 2/6] ipv6: Append sending data to arbitrary queue Vladislav Yasevich
2015-01-31 15:40 ` [PATCH net-next 3/6] ipv6: introduce ipv6_make_skb Vladislav Yasevich
2015-01-31 15:40 ` [PATCH net-next 4/6] ipv6: Introduce udpv6_send_skb() Vladislav Yasevich
2015-01-31 15:40 ` [PATCH net-next 5/6] udpv6: Add lockless sendmsg() support Vladislav Yasevich
2015-01-31 20:49   ` Sergei Shtylyov
2015-02-02 20:42     ` Vlad Yasevich
2015-01-31 15:40 ` [PATCH net-next 6/6] ipv6: Allow for partial checksums on non-ufo packets Vladislav Yasevich
2015-02-10 14:07   ` Sabrina Dubroca [this message]
2015-02-10 15:34     ` Vlad Yasevich
2015-02-10 15:55     ` [PATCH] ipv6: Partial checksum only UDP packets Vladislav Yasevich
2015-02-10 16:23       ` Sabrina Dubroca
2015-02-03  3:28 ` [PATCH net-next 0/6] ipv6: Add lockless UDP send path David Miller

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=20150210140704.GA3372@kria \
    --to=sd@queasysnail.net \
    --cc=hannes@stressinduktion.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev@vger.kernel.org \
    --cc=vyasevic@redhat.com \
    --cc=vyasevich@gmail.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 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).