All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ramu Ramamurthy <sramamur@linux.vnet.ibm.com>
To: Tom Herbert <tom@herbertland.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Jiri Benc <jbenc@redhat.com>, James Morris <jmorris@namei.org>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>,
	pradeeps@linux.vnet.ibm.com, J Kidambi <jkidambi@us.ibm.com>
Subject: Re: [PATCH] - vxlan: gro not effective for intel 82599
Date: Fri, 26 Jun 2015 14:44:29 -0700	[thread overview]
Message-ID: <0fbeed20a897eeebdeececa0bb68fa72@imap.linux.ibm.com> (raw)
In-Reply-To: <CALx6S37+es-QD-_41O4cc59_oEX2UeeibZgjd8uOvTcPMHO+nA@mail.gmail.com>

On 2015-06-26 12:59, Tom Herbert wrote:
> On Fri, Jun 26, 2015 at 12:31 PM, Ramu Ramamurthy
> <sramamur@linux.vnet.ibm.com> wrote:
>> On 2015-06-26 11:04, Tom Herbert wrote:
>>>> 
>>>> 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.
>> 
>> 
>> Heres more details on the test.
>> 
>> gro is "on" on the device and the tunnel. tcpdump on the vxlan 
>> interface
>> show un-aggregated packets
>> 
>> [root@ramu1 tracing]# tcpdump -i vxlan0
>> <snip>
>> ptions [nop,nop,TS val 1972850548 ecr 193703], length 1398
>> 14:14:38.911955 IP 1.1.1.21.44134 > 1.1.1.11.commplex-link: Flags [.], 
>> seq
>> 224921449:224922847, ack 1, win 221, options [nop,nop,TS val 
>> 1972850548 ecr
> 
> Looks like GRO was never implemented for vxlan tunnels. The driver is
> simply calling netif_rx instead of using the GRO cells infrastructure.
> geneve is doing the same thing. For other tunnels which are used in
> foo-over-udp (GRE, IPIP, SIT) ip_tunnel_rcv is called which in turn
> calls gro_cells_receive.

Can we remove or (relax) the checksum checks in udp_gro_receive() which 
are immediately
preventing the vxlan_gro callbacks from being called from 
udp_gro_receive() ?
vxlan driver is registering these offloads callbacks, and I can see them 
work when i
relax the following checksum checks.

	if (NAPI_GRO_CB(skb)->udp_mark ||
	    (skb->ip_summed != CHECKSUM_PARTIAL &&      <<<<  remove or relax 
these checks
	     NAPI_GRO_CB(skb)->csum_cnt == 0 &&         <<<<  which are 
directly
	     !NAPI_GRO_CB(skb)->csum_valid))            <<<<  dependent on nic 
capability
		goto out;

Alternatively, can we move these checks to the respective drivers' 
gro_receive() function.

The other changes you suggest (gro_cells) are beyond my understanding.

  reply	other threads:[~2015-06-26 21:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-26  0:03 [PATCH] - vxlan: gro not effective for intel 82599 Ramu Ramamurthy
2015-06-26  0:20 ` Tom Herbert
2015-06-26  1:06   ` Ramu Ramamurthy
2015-06-26  2:57     ` Tom Herbert
2015-06-26  5:15       ` Eric Dumazet
2015-06-26 17:24         ` Tom Herbert
2015-06-26 17:36       ` Ramu Ramamurthy
2015-06-26 18:04         ` Tom Herbert
2015-06-26 19:31           ` Ramu Ramamurthy
2015-06-26 19:59             ` Tom Herbert
2015-06-26 21:44               ` Ramu Ramamurthy [this message]
2015-06-28 20:19               ` Or Gerlitz
2015-06-28 21:17                 ` Tom Herbert
2015-06-29 19:56                   ` Ramu Ramamurthy

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=0fbeed20a897eeebdeececa0bb68fa72@imap.linux.ibm.com \
    --to=sramamur@linux.vnet.ibm.com \
    --cc=davem@davemloft.net \
    --cc=jbenc@redhat.com \
    --cc=jkidambi@us.ibm.com \
    --cc=jmorris@namei.org \
    --cc=netdev@vger.kernel.org \
    --cc=pradeeps@linux.vnet.ibm.com \
    --cc=tom@herbertland.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.