[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALx6S35-GKW+hgn-9Y5a87hETfetKuusALFUDZ5vzwrtQSiypA@mail.gmail.com>
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
Powered by blists - more mailing lists