From: Vlad Yasevich <vyasevic@redhat.com>
To: Sabrina Dubroca <sd@queasysnail.net>,
Vladislav Yasevich <vyasevich@gmail.com>
Cc: netdev@vger.kernel.org, herbert@gondor.apana.org.au,
hannes@stressinduktion.org
Subject: Re: [PATCH net-next 6/6] ipv6: Allow for partial checksums on non-ufo packets
Date: Tue, 10 Feb 2015 10:34:12 -0500 [thread overview]
Message-ID: <54DA24F4.9030506@redhat.com> (raw)
In-Reply-To: <20150210140704.GA3372@kria>
On 02/10/2015 09:07 AM, Sabrina Dubroca wrote:
> 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?
Hi Sabrina
Thanks for reporting this. I'll take a look.
-vlad
>
>
> Thanks
>
next prev parent reply other threads:[~2015-02-10 15:35 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
2015-02-10 15:34 ` Vlad Yasevich [this message]
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=54DA24F4.9030506@redhat.com \
--to=vyasevic@redhat.com \
--cc=hannes@stressinduktion.org \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
--cc=sd@queasysnail.net \
--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).