lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALx6S34F1WTH=+2LZT483KAi3CC5uK3aniTHuufi=gzch-b6vQ@mail.gmail.com>
Date:	Fri, 26 Jun 2015 10:24:46 -0700
From:	Tom Herbert <tom@...bertland.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Ramu Ramamurthy <sramamur@...ux.vnet.ibm.com>,
	"David S. Miller" <davem@...emloft.net>,
	Tom Herbert <therbert@...gle.com>,
	Jiri Benc <jbenc@...hat.com>, James Morris <jmorris@...ei.org>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	pradeeps@...ux.vnet.ibm.com, J Kidambi <jkidambi@...ibm.com>
Subject: Re: [PATCH] - vxlan: gro not effective for intel 82599

On Thu, Jun 25, 2015 at 10:15 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Thu, 2015-06-25 at 19:57 -0700, Tom Herbert wrote:
>
>> That may be, but this change would affect all uses of GRO with UDP
>> encapsulation not just for intel 10G NICs. For instance, pushing a lot
>> of checksum calculation into the napi for a single queue device could
>> overwhelm the corresponding CPU-- this is the motivation for the
>> restriction in the first place. We need to do a little more diligence
>> here.
>
> We made the choice of computing checksums years ago when GRO was enabled
> for GRE packets, as many NIC are not able to validate TCP checksums with
> this configuration.
>
But we only started computed checksums for GRE in the device napi with
Jerry's patch:

commit bf5a755f5e9186406bbf50f4087100af5bd68e40
Author: Jerry Chu <hkchu@...gle.com>
Date:   Tue Jan 7 10:23:19 2014 -0800

    net-gre-gro: Add GRE support to the GRO stack

Or's patch to support GRO for UDP encapsulation which included a check
for checksum complete was accepted a mere 13 days later :-)

We have the option of performing GRO at the tunnel interface and that
is good if we need to do checksum calculation since it is post packet
steering and could heat up cache for an application. If we remove the
checksum check in the udp_gro_receive then the only way to push the
GRO to be done in the tunnel interface would be to disable GRO for
everyone on the Ethernet device. I suspect Ramu's results are without
GRO enabled on the tunnel interface and getting no GRO at all can be
very expensive of course.

Anyway, I am looking at solutions and trying to repro the results.

Tom








> Sure, in some cases this can increase load on softirq handlers, but
> there are some ways to spread load on multi queue NIC.
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ