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