All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Paolo Abeni <pabeni@redhat.com>, netdev@vger.kernel.org
Cc: eric.dumazet@gmail.com, Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Subject: Re: unexpected GRO/veth behavior
Date: Mon, 10 Sep 2018 07:56:46 -0700	[thread overview]
Message-ID: <f84e9363-bdc0-5e41-ca1a-99f612fcc708@gmail.com> (raw)
In-Reply-To: <4106d3f7eee7f0186fcfdd0331cdafeecd3240c0.camel@redhat.com>



On 09/10/2018 07:44 AM, Paolo Abeni wrote:
> hi all,
> 
> while testing some local patches I observed that the TCP tput in the
> following scenario:
> 
> # the following enable napi on veth0, so that we can trigger the
> # GRO path with namespaces
> ip netns add test
> ip link add type veth
> ip link set dev veth0 netns test
> ip -n test link set lo up
> ip -n test link set veth0 up
> ip -n test addr add dev veth0 172.16.1.2/24
> ip link set dev veth1 up
> ip addr add dev veth1 172.16.1.1/24
> IDX=`ip netns exec test cat /sys/class/net/veth0/ifindex`
> 
> # 'xdp_pass' is a NO-OP XDP program that simply return XDP_PASS
> ip netns exec test ./xdp_pass $IDX &
> taskset 0x2 ip netns exec test iperf3 -s -i 60 &
> taskset 0x1 iperf3 -c 172.16.1.2 -t 60 -i 60
> 
> is quite lower than expected (~800Mbps). 'perf' shows a weird topmost 
> offender:
>


But... why GRO would even be needed in this scenario ?

GRO is really meant for physical devices, having to mess with skb->sk adds extra cost
in this already heavy cost engine.

Virtual devices should already be fed with TSO packets.

  reply	other threads:[~2018-09-10 19:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-10 14:44 unexpected GRO/veth behavior Paolo Abeni
2018-09-10 14:56 ` Eric Dumazet [this message]
2018-09-10 15:22   ` Paolo Abeni
2018-09-10 17:06     ` Eric Dumazet
2018-09-11  0:33   ` Toshiaki Makita
2018-09-11  6:54 ` Paolo Abeni
2018-09-11 10:27   ` Eric Dumazet
2018-09-11 11:07     ` Toshiaki Makita
2018-09-14  2:51       ` Toshiaki Makita
2018-09-11 11:44     ` Paolo Abeni
2018-09-11 15:42       ` Eric Dumazet

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=f84e9363-bdc0-5e41-ca1a-99f612fcc708@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=makita.toshiaki@lab.ntt.co.jp \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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.