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.
next prev parent 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.