netdev - Re: [PATCH] - vxlan: gro not effective for intel 82599

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]

Date:	Fri, 26 Jun 2015 11:04:51 -0700
From:	Tom Herbert <tom@...bertland.com>
To:	Ramu Ramamurthy <sramamur@...ux.vnet.ibm.com>
Cc:	"David S. Miller" <davem@...emloft.net>,
	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

> I am testing the simplest configuration which has 1 TCP flow generated by
> iperf from
> a VM connected to a linux bridge with a vxlan tunnel interface. The 10G nic
> (82599 ES) has
> multiple receive queues, but in this simple test, it is likely immaterial
> (because, the
> tuple on which it hashes would be fixed). The real difference in performance
> appears to
> be whether or not vxlan gro is performed by software.
>

Please do "ethtool -k vxlan0" of whatever interface is for vxlan.
Ensure GRO is "on", if not enable it on the interface by "ethtool _k
vxlan0 gro on". Run iperf and to tcpdump on the vxlan interface to
verify GRO is being done. If we are seeing performance degradation
when GRO is being done at tunnel versus device that would be a
different problem than no GRO being done at all.
--
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