From: Alexander Duyck <alexander.duyck@gmail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Alexander Duyck <alexander.h.duyck@intel.com>,
Dmitry Kravkov <dmitry@broadcom.com>,
netdev@vger.kernel.org, stephen@networkplumber.org,
pshelar@nicira.com, joseph.gasparakis@intel.com,
jesse@nicira.com, Eilon Greenstein <eilong@broadcom.com>
Subject: Re: [PATCH net v2] gso: Update tunnel segmentation to support Tx checksum offload
Date: Wed, 10 Jul 2013 19:30:57 -0700 [thread overview]
Message-ID: <51DE18E1.304@gmail.com> (raw)
In-Reply-To: <1373507037.4600.34.camel@edumazet-glaptop>
On 07/10/2013 06:43 PM, Eric Dumazet wrote:
> On Wed, 2013-07-10 at 17:42 -0700, Eric Dumazet wrote:
>> On Wed, 2013-07-10 at 17:05 -0700, Alexander Duyck wrote:
>>> This change makes it so that the GRE and VXLAN tunnels can make use of Tx
>>> checksum offload support provided by some drivers via the hw_enc_features.
>>> Without this fix enabling GSO means sacrificing Tx checksum offload and
>>> this actually leads to a performance regression as shown below:
>>>
>>> Utilization
>>> Send
>>> Throughput local GSO
>>> 10^6bits/s % S state
>>> 6276.51 8.39 enabled
>>> 7123.52 8.42 disabled
>> While testing your patch, I discovered TSO support is completely broken
>> on GRE, using bnx2x testbed.
>>
>> Oh well.
>>
>> It seems Nicira guys do not test a lot their patches.
>>
I think part of the problem is that there aren't really many devices
that support any hardware offloads at this point. Thus, in the case of
GSO, it wasn't really easy to notice the issue if you don't have a
device capable of doing the offloads. I may look at seeing if we can
push a patch I had for enabling Tx encapsulated checksum offload for
ixgbe and maybe igb as at least that way we have a common platform to do
some testing with.
> Receiver receives corrupted frames : IpExtInCsumErrors is increasing
>
> The outer checksum is not correct.
>
> Maybe Dmitry has an idea of what is going on ?
>
> 18:36:06.085164 IP (tos 0x0, ttl 64, id 48051, offset 0, flags [DF],
> proto: GRE (47), length: 1500, bad cksum 3fad (->40ad)!) 10.246.17.83 >
> 10.246.17.84: GREv0, Flags [none], length 1480
> IP (tos 0x0, ttl 64, id 48051, offset 0, flags [DF], proto: TCP (6),
> length: 1476) 7.7.8.83.52523 > 7.7.8.84.48165: ., cksum 0x88b9
> (correct), 1:1425(1424) ack 1 win 449 <nop,nop,timestamp 1901210
> 83620016>
>
> 18:36:06.085165 IP (tos 0x0, ttl 64, id 48051, offset 0, flags [DF],
> proto: GRE (47), length: 1500, bad cksum 3fad (->40ad)!) 10.246.17.83 >
> 10.246.17.84: GREv0, Flags [none], length 1480
> IP (tos 0x0, ttl 64, id 48052, offset 0, flags [DF], proto: TCP (6),
> length: 1476) 7.7.8.83.52523 > 7.7.8.84.48165: ., cksum 0x8329
> (correct), 1425:2849(1424) ack 1 win 449 <nop,nop,timestamp 1901210
> 83620016>
>
> 18:36:06.085166 IP (tos 0x0, ttl 64, id 48051, offset 0, flags [DF],
> proto: GRE (47), length: 1500, bad cksum 3fad (->40ad)!) 10.246.17.83 >
> 10.246.17.84: GREv0, Flags [none], length 1480
> IP (tos 0x0, ttl 64, id 48053, offset 0, flags [DF], proto: TCP (6),
> length: 1476) 7.7.8.83.52523 > 7.7.8.84.48165: ., cksum 0x7d99
> (correct), 2849:4273(1424) ack 1 win 449 <nop,nop,timestamp 1901210
> 83620016>
It was my understanding that the code for enabling TSO for encapsulated
frames was good as Joseph has been working on it and testing it for
i40e. I'm assuming if you turn off TSO then the GSO and Tx checksum are
working correctly? I just want to make sure the issue you are seeing
isn't in any way related to my patch.
Thanks,
Alex
next prev parent reply other threads:[~2013-07-11 2:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-11 0:05 [PATCH net v2] gso: Update tunnel segmentation to support Tx checksum offload Alexander Duyck
2013-07-11 0:42 ` Eric Dumazet
2013-07-11 1:43 ` Eric Dumazet
2013-07-11 2:30 ` Alexander Duyck [this message]
2013-07-11 2:37 ` Eric Dumazet
2013-07-11 2:23 ` Cong Wang
2013-07-11 7:45 ` Pravin Shelar
2013-07-11 8:14 ` David Miller
2013-07-11 8:31 ` Dmitry Kravkov
2013-07-11 13:51 ` Eric Dumazet
2013-07-11 17:58 ` Alexander Duyck
2013-07-11 19:19 ` 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=51DE18E1.304@gmail.com \
--to=alexander.duyck@gmail.com \
--cc=alexander.h.duyck@intel.com \
--cc=dmitry@broadcom.com \
--cc=eilong@broadcom.com \
--cc=eric.dumazet@gmail.com \
--cc=jesse@nicira.com \
--cc=joseph.gasparakis@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pshelar@nicira.com \
--cc=stephen@networkplumber.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 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).