netdev - Performance loss with GRO enabled on tunnels

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-next>] [day] [month] [year] [list]

Message-ID: <CA+mtBx9uvD7Ddg4xQxDKxFK395ccEc3YvwhFVZJU9xJvUsAdGg@mail.gmail.com>
Date:	Thu, 26 Jun 2014 17:59:16 -0700
From:	Tom Herbert <therbert@...gle.com>
To:	Linux Netdev List <netdev@...r.kernel.org>
Subject: Performance loss with GRO enabled on tunnels

I'm seeing quite a performance difference with GRO enabled/disabled on
the tun interface for GRE and IPIP. Physical interface is bnx2x with
lro enable and GRO disabled. Looks like tun interface inherits GRO as
an "always supported SW feature".

200 connection TCP_RR with GRE and no GRO on tun0
  1.06046e+06 tps
  71.06% CPU utilization

With GRO enabled on tun0
  406879 tps
  28.14% CPU utilization

Given CPU utilization is not particularly high, so I would guess
things are being slowed down by something like lock contention.

Generally, I wonder if there's really any value on enabling GRO on the
tunnel interface anyway, seems like GRO is going to be most beneficial
if we do this at the physical device-- if we're aggregating at the
tunnel interface we've already done a lot of processing on the
individual packets.

Tom
--
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