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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CO2PR11MB0088207088FA6F6A502AB3B097EA0@CO2PR11MB0088.namprd11.prod.outlook.com>
Date:   Wed, 24 Aug 2016 12:33:49 +0000
From:   Yuval Mintz <Yuval.Mintz@...gic.com>
To:     Alexander Duyck <aduyck@...antis.com>,
        netdev <netdev@...r.kernel.org>
Subject: RE: [RFC PATCH 3/5] bnx2x: Add support for segmentation of tunnels
 with outer checksums

> This patch assumes that the bnx2x hardware will ignore existing IPv4/v6 header
> fields for length and checksum as well as the length and checksum fields for
> outer UDP and GRE headers.
> 
> I have no means of testing this as I do not have any bnx2x hardware but thought
> I would submit it as an RFC to see if anyone out there wants to test this and see
> if this does in fact enable this functionality allowing us to to segment tunneled
> frames that have an outer checksum.
> 
> Signed-off-by: Alexander Duyck <aduyck@...antis.com>

So it took me some [well, a lot] time to reach this, but I've finally  gave it a try.
I saw a performance boost with the partial support -
Throughput for vxlan tunnels with and without udpcsum were almost identical
after this, whereas without this patch the udpcsum prevented GSO and 
a TCP/IPv4 connection on top of it got roughly half the throughput.

However, I did encounter one oddity I couldn't explain -
After I've disabled tx-udp_tnl-segmentation via ethtool on the base interface,
got left with:
   tx-gso-partial: on
   tx-udp_tnl-segmentation: off
   tx-udp_tnl-csum-segmentation: on

When I ran traffic over both vxlan tunnels the one with the udpcsum was still
Passing gso aggregations to base device to transmit [and the throughput was
same as before], where's the tunnel without the udpcsum showed only
MTU-sized packets reaching the base interface for transmission [which is what
I've expected]

Any idea why that happened?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ